Tag: Communication

The Business Analyst: When Not Knowing the Answer is OK

Written by Josh Jones on March 5, 2012. Posted in Articles. 1 Comment on The Business Analyst: When Not Knowing the Answer is OK

A new project has spun up and you’ve been assigned as the Business Analyst (the same scenario outlined below could happen if you are added to a project that was already in flight). You’ve done your diligence preparing; you’ve read the scope, reviewed the charter document and called your first requirements gathering meeting with the business partners and IT representatives. Your meeting is underway and while you’re attentively listening to the business SME explain the detailed process for transferring a policy from one agency to another, you find yourself feverishly jotting down notes as the nuggets of information being thrown out are too juicy not to capture. Then it hits you: you have no idea what the business SME is talking about!

Though your notes are word-for-word with what the business SME is saying, they might as well be a foreign language that you don’t speak. The fear of looking foolish or not wanting to lose creditability in the eyes of the project team, you do your best to keep writing while desperately trying to grasp the concepts that the SME is laying out in front of you. When first assigned to a project, this is where most BAs get tripped up.

In my experience (ten years in the BA and PM space), I’ve been there many times. And it wasn’t until a few years ago that I finally figured out how to handle the situation described above successfully. No matter how seasoned of a Business Analyst you are, a situation like the one above will happen. It’s inevitable. It’s very rare for a BA — no matter how much experience they have — to start every project with knowledge that will allow them to know what’s going on at all times for all scenarios.

The hardest parts of when you don’t know the answer is 1) trying not to look dumb in the eyes of fellow project team members 2) knowing how to make sense of what is being said and 3) being able to take the information given to you — at a time when it makes no sense whatsoever — and produce relevant (and accurate!) requirements.

There are four simple tricks you can use to get you out of the jam of not knowing the subject matter yet still get something out of the meeting.

· First, use your “Veil of Unfamiliarity.” As a contracting BA, I have many clients. And most of the time, when I work with a client, I know very little about the interworkings of their internal process, knowledge workflow and system-to-system linkage. But that doesn’t stop me from quickly picking up the things I don’t know. When I find myself new to a client, I often stand behind my “veil of unfamiliarity.” What I mean is even though you have all the best analysis skillsets in your toolbox, they are useless unless you know how to use them on a project. When I find myself on a brand new project that I know very little about, I will often say (out loud), “Since I’m new to this subject matter, I’m going to step behind my veil of unfamiliarity for a moment, could you explain that in more detail?” This is similar to asking the client, “Would you mind putting what you just said into easier-to-understand terms/language?” The reason you want to use your veil is so you can understand the unfamiliar topic at a higher level (less detail) before later diving into the weeds of that particular process flow or UI functionality or whatever it is that you’re trying to understand. In other words, you are openly admitting that you aren’t familiar with the details of the subject matter…yet. Being open and honest by asking the client to make the topic easier for you to understand will further strengthen that trust relationship with the project team and business partners. Using your “Veil of Unfamiliarity” is another way of saying, “I don’t know what you’re talking about yet, but I will soon,” all the while saving face (protecting your integrity) with the project team.

· Second, look for action items — even if they aren’t for the BA — and insert yourself into them (when it makes sense, of course). Another trick I’ve found to work well is to associate myself to follow-up action items that come out of a meeting even if they don’t directly involve me. Take the opportunity early in a new project to absorb and learn as much as you possibly can. It doesn’t matter where the source is either; just immerse yourself in anything topical to the project. Of course, it goes without saying that you should take care of your BA responsibilities first, but if you have the chance to sit in on a meeting with IT as they review a design document or sit with the business partners as they figure out how they want to incorporate their needs into deliverables, do it. Even though some of the action items aren’t directly tied to your BA work on the project, you’ll be building that background knowledge that will come in handy later on in the project.

· Next, create a partnership with the Business SME (or wherever the knowledge is). While it’s always important for the BA to have a healthy partnership with the Project Manager, it’s just as important to have a healthy, open partnership with the Business SME. After all, they are the ones whose needs must be met by the project. More often than not, this relationship is overlooked, not in place or undervalued, and can lead to limited — or in worst cases broken communication — between you (the BA) and them (the owner’s for the needs/business requirements). If you want to be successful in the BA space, you must value the partnership with the business SME. It will be so much easier to get vital information quickly when the partnership with the Business SME is healthy, strong and open.

· Lastly, and probably the hardest trick of all, is to be humble and ask. This is the simplest trick to grasp, but also the hardest to actually do. If you are like me at the start of a new project, you’re cautious of exposing your proverbial underbelly to a new project team. By that, I mean you’re hesitant to let your colleagues know that you have a vulnerability around fully understanding the subject at hand right out of the gate. However, if you don’t speak up now (at the beginning of when you start a project), it’s too late. Because the role of the BA is so vital to the overall success of a project, you should never pass up the opportunity in the beginning to ask the business SME — or anyone else on the project team for that matter — to clarify their comments if you do not understand them. It could be comments about scope, business needs, requirements, functional specs or anything project related. The point is, it doesn’t matter what the topic is: if you aren’t crystal clear with your (the BA’s) understanding, ask them to clarify their statement(s). More often than not, the requirements phase of a project moves at light speeds, so it’s important to level-set expectations of understanding the subject matter early and often in order to avoid getting left in the dust. And if you’re worried about losing creditability in the beginning of a project for not knowing the subject in detail, just imagine how much creditability you’ll lose when you get three weeks into requirements gathering sessions and you still don’t know what’s going on. Trust me, I’ve seen it happen and it’s not pretty! In the end, the business SME — or whoever is providing the clarity — would rather provide more clarity on a topic that you asked about than find out you (the BA) did not fully understand it.

Too often, I’ve seen good business analysts lose credibility with a project team because they aren’t willing to admit that they don’t know something. Fearing they will be ridiculed, the BA will play along like they know the subject matter, but when it comes down to crunch time on a project and they aren’t as well versed in something they’ve said they are, then that is when the requirements are at risk of being incomplete, or worse, incorrect. It doesn’t have to be that way! The next time you find yourself sitting in a project meeting or requirements gathering session and you don’t know the answer to a question or don’t know how a business process works, try using one of the tips in this article to assist you with gaining a better, clearer understanding of the subject. In the end, you will thank yourself for being bold enough to put aside your fear of losing credibility and doing what it takes to have a clear, concise understanding of the topic at hand. By doing that, you will have put yourself in the position to produce solid, real and most importantly, accurate requirements.

Don’t forget to leave your comments below.

Josh Jones is a seasoned BA with over 9 years of experience in the BA and PM space. Josh has successfully applied project and analysis leadership expertise to deliver project initiatives in a wide variety of industries (including product fulfillment and distribution, insurance, broker dealer management, Life and Annuities products, information technology, network services, financial services, investment/retirement products, and agriculture).

As a mentor and BA coach, Josh’s hands-on, “create a solid partnership” approach blends his desire to share his business analysis expertise with his passion for helping others improve.

The Business Analyst as Explorer, Part 6 of 6 – Why Ask Why?

Written by Karl Wiegers on February 21, 2012. Posted in Articles. 2 Comments on The Business Analyst as Explorer, Part 6 of 6 – Why Ask Why?

“Why?” is an excellent question to put in the business analyst’s bag of tricks. During a reengineering project, a BA named Dawn asked one of the developers why a utility company fee calculation was being performed a certain way in the existing system. “There’s a government statute that dictates how we have to calculate these fees,” was the reply. Upon investigation, Dawn discovered that in fact the current system had not implemented the computation correctly according to that statute. The system had calculated these utility fees incorrectly for an embarrassingly long time. This discrepancy never would have come to light had Dawn simply accepted the stated need for the current formula. Asking “why” revealed a major error that the replacement system corrected.

The shrewd BA asks why a lot. It’s important that “why” explorations be expressed in a way that doesn’t sound confrontational, accusatory, or challenging. I often ask questions that begin this way: “Can you please help me understand…” This phrase is longer than whyand means essentially the same thing, but it has a more collaborative feel to it.

When a user representative presents a requirement that contains an embedded solution idea, asking why can let you know whether the solution idea is a true design constraint or just an idea or suggestion. Asking why several times in succession is a way to drill down from a superficially proposed customer “want” to the real underlying need. This helps the software team address the real issue, not just a superficially presented issue. Gently probing with why can reveal other sorts of useful information:

The answer to why might point out a business rule that affects the project. Then you can check to see whether the business rule is still pertinent and whether the information you have available for it is complete and accurate. You can discover whether and where the business rule is documented, who’s responsible for maintaining the information, and whether there are related rules you need to know about.
Asking why sometimes surfaces assumptions held by the person you’re questioning. An assumption is a statement that you regard as being true in the absence of definitive knowledge that it is true. It’s important to try to identify assumptions that various stakeholders might be making. Those assumptions could be incorrect or obsolete. They could be at odds with assumptions other people are making. Such conflicts make it harder for the stakeholders to have shared project expectations.
Asking why can reveal implicit requirements that no one thought to mention yet.
The answer to “Why is this requirement included?” supplies the rationale behind the requirement. It’s always a good idea to know where each requirement came from and why it needs to be included in the project. This can help the BA learn about requests that lie outside the project scope. This question sometimes also exposes that the “requirement” is really a design idea for an unstated higher-level requirement.
Suppose you encounter a requirement that a user representative presented as being high priority. It doesn’t look that important or urgent to you. If you ask why it’s high priority, perhaps you’ll learn that it’s logically connected to other requirements that also are high priority. Without this knowledge, someone might unwittingly defer the requirement that doesn’t seem so important, thereby crippling the related requirements that are scheduled for early implementation.
Sometimes the BA thinks she understands a requirement, only to discover upon further investigation that she really doesn’t. Asking why a requirement is necessary a few times could provide additional details that solidify the BA’s understanding of that requirement.
Asking why or similar questions can help the BA distinguish essential requirements knowledge from extraneous information.

Asking why might save you a lot of work. One project was replacing an existing customer relationship management (CRM) system with a package solution. Senior management directed the team to use out-of-the-box features from the package as much as possible and to limit the extent of configuration or changes to the package. One user representative asked that a specific function be added, a counter that indicated how many times a customer had used a certain product feature. It would have cost a significant amount to modify the core package to accommodate this requirement.

When the BA asked why that function was needed, the user said that the function was present in the current CRM application. The BA probed further: “What exactly does this counter show?” “Why do you check it?” “What action do you take depending on what it tells you?” This discussion eventually revealed that several stakeholders all thought that someone else was using the data. In reality, no one used it at all! By asking “why” a few times, the BA and user representative agreed that the function wasn’t needed, thereby saving a significant amount of money.

A BA needs to be a bit of a skeptic. Don’t believe everything you hear, and don’t accept it all at face value. Ask “why” enough times to give you confidence that you’ve got the real requirements in hand.

(adapted from More about Software Requirements by Karl Wiegers)

Don’t forget to add your comments below.

Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons. Karl produced this article for Enfocussolutions.

BI – This Is Why

Written by Salah Elleithy on November 21, 2011. Posted in Articles.

Business Intelligence has been a buzzword for years. Organizations saw it as optional or unnecessary. In the current environment, Business Intelligence has become a necessity. Organizations in any industry look for relevant information to make decisions.

Just as cash is the lifeblood of any organization. Data is the lifeblood of any information system in the organization. The importance of collecting data in a systematic and structured way is critical to the success of any business. Management needs to have visibility into all aspects of the business. Not only from a financial point of view but also other metrics that are critical to measuring the business success such as operations, compliance and HR. Accuracy and speed are among the most critical factors. We will discuss the importance of how business intelligence play a major role in providing the organization with the critical information it needs to make good decisions. We will focus on why business intelligence is important and how to implement a business intelligence solution.

Business Intelligence (BI)

Almost half a century ago, P. Hans Luhn, an IBM researcher defined business intelligence as the ability to apprehend the interrelationships of presented facts in such a way as to guide action towards a desired goal. This definition is still relevant today. No longer can management wait for historical information to make future decisions. Fact or evidence based systems have become critical to any organization.

In the past when data was not available, decisions were made based on intuition and “gut feelings”. Today in a dynamic and ever changing business world, data drives decision-making.

Healthcare is one of the major industries that could benefit from BI. Organizations in the healthcare industry have to quickly adapt to satisfy government regulations whether on the state or federal level. The need to build systems that are robust and adaptable to change is inevitable. The current challenges range from collecting data in a systematic and consistent way to securing the data to the ability of providing accurate and timely reporting and analysis. BI could be the spark that exposes different metrics to help healthcare organizations identify ways to improve quality.

Benefits of Business Intelligence

Data collected in the healthcare industry usually falls into one of three categories: Financial, Clinical and Operational. Within each of those categories, there are multiple variations of analysis that need to be sliced and diced in different ways. BI will provide information, develop knowledge about financial, clinical and operational metrics that will impact decision-making behavior to improve quality of care and achieve higher profitability.

Some of the benefits and improvements that can be reaped from implementing a business intelligence solution are:

1. Quality of care:

A healthcare provider such as a hospital or a home health facility main goal is to improve quality of care for patients. BI is not only used for operational and financial purposes. With the vast amount of stored clinical data including patient history, BI could help identify better ways of monitoring and treating our patients. Implementing a fact based system with analytics not only help clinicians and doctors better asses the trends and monitor improvement for their patients, it could provide insights on treatment outcomes that would enhance quality of care. This will provide a competitive advantage to any healthcare organization.

2. Strategy

What is measured improves, said Peter Drucker. Without measuring where we are today, we cannot plan where we want to be tomorrow. Using BI to develop metrics to monitor clinical, operational and financial information will help the organization with setting long-term goals and develop future strategy.

3. Speed

We need information and we need it fast. BI tools provide us with the ability to analyze data in multiple ways. It summarizes massive amount of data into variety of reporting formats such as dashboards and graphical representation to enable healthcare management to act quickly in a dynamic environment.

4. Accuracy

Providing accurate information is critical. Bad information leads to bad decisions. In healthcare, bad decisions could impact the livelihood of patients. BI uses visual capabilities that make finding inaccuracies more efficient. Identifying inaccuracies will serve as a red flag to correct the issues and minimize the risks associated with them.

5. Enhancing Decision Making

Using BI improves the decision making process. The steps of making a decision involve four different stages: intelligence (problem discovery), design (solution discovery), choice (choosing solutions), and implementation (solution testing). This process is iterative and can take a long time to run through different scenarios before finding a solution that could work. BI can significantly reduce this cycle of decision making by providing different scenarios and changing them on the fly to get instant reporting and analysis. It also allows us to visually see the impact whether it is on a summarized or a more granular level.

Selecting a BI Solution

There are many vendors providing BI platforms in the market today. Some of which have a great market share and an established track record. When selecting BI solutions, some of the factors we need to consider are:

1. Understanding our needs:

In order to choose a BI solution, we must first understand what we want to get out of the BI solution. What it is supposed to do and what are problems we are trying to solve by implementing the BI solution.

2. Ease of Use:

One of the main goals of implementing a BI solution is to give users the tools to analyze data. The BI solution learning curve has to be minimal in order to be adapted by the users. Training should be easily available and provide users with a quick understanding of how to use the BI tool. The BI solution need to be designed to empower developers to rapidly build BI applications that can be utilized by employees at all levels. This expands business intelligence far beyond analysts and power users – who have always been able to employ complex BI tools – and makes it readily available to line of business workers who require operational reporting to support their day-to-day activities and drive process efficiencies across functions.

3. Scalability:

BI solutions are selected to provide a greater impact on operational efficiency. This means that BI solutions need to scale to all levels of the organizations without the need for costly upgrades or great deal of maintenance. The availability to users is very important, as they will utilize the BI solution to analyze their operations and make decisions based on the analysis.

4. Information Sharing:

Information is mostly a “Pull and Push” process. Users pull information to share it with their team, customers, suppliers and others who need to know and act upon the information shared. The BI solution needs to allow the user to share the information efficiently. Most users share information by email, which is static. The information sharing process has to be more dynamic where once the data is updated; it is automatically update for the user. This can be accomplished by utilizing the web interface as a delivery method of the BI solution.

5. Integration:

Most organizations have multiple systems for different functions. The BI solutions must have the ability to easily integrate with current in house systems. BI solution is required to integrate with back-end systems in order to solve a problem. Organizations may need more integration tools however BI solutions should have the ability to integrate with major databases and file formats.

Implementing a BI Solution

The key elements of an organization are its People, Structure, Business processes, Politics and Culture. Implementing a new technology will impact those elements and should be addressed accordingly.

BI is a front-end technology that analyzes data. The Challenge is to put the structure in place to get the highest return on investment (ROI) of the BI solution. The data and systems have to be ready to implement a BI solution. Another challenge we face is once the technology is in place is how to get people to learn it and use it.

Data represent a key challenge since it is stored in different systems across the board. In order to solve this problem, a data warehouse needs to be developed. A data warehouse is created to centralize data into one place and is optimized for analytics needs. This is a huge undertaking but is necessary if we are looking to get a high ROI on our BI solution.

Summary

Business Intelligence (BI) is a culture change and not just a technology. Systems and structure have to be in place to fully leverage the BI solution. That being said, we can’t afford to wait until the systems and structure are in place. Our approach should be one that allows us to grow into the BI solution. BI can highlight data and system inefficiencies, therefore we need to implement a cost effective BI solution as a pilot. This is how a learning organization approaches new technology to reduce the risk of failure and understand the groundwork that needs to be done for it to be successful.

Don’t forget to leave your comments below.

Salah Elleithy, PMP, is an experienced Business analyst with a decade of experience in a diverse array of industries. He is passionate about performance management and data analytics. He has a wide experience in business development, business intelligence, and decision support to senior management. Salah worked on a portfolio of projects to develop a variety of metrics in the energy, pharmaceutical and health industries. Salah is also passionate about teaching and he volunteers with many organizations. You can follow him on twitter (@selleithy).

References

“A Business Intelligence System”, IBM Journal, October 1958, P. Luhn. http://www.research.ibm.com/journal/rd/024/ibmrd0204H.pdf (Link has been moved to IEEE)

Foundation of Business Intelligence: Databases and Information Management. K. and J. Laudon. Chapter 6, PP 222-223

Healthcare Tech: Can BI Save the System? InformationWeek. August 2009, Boris Eveleson

http://www.informationweek.com/news/healthcare/interoperability/showArticle.jhtml;jsessionid=W1Z0ZH23HDHPFQE1GHRSKH4ATMY32JVN?articleID=219300177&pgno=2&queryText=&isPrev=

Business Intelligence in the Healthcare Industry, http://www.hypatiaresearch.com/images/HypatiaResearch_2BIinHEALTHCARE_ExecSum_TOC.pdf

Applying Business Intelligence to the Needs of Healthcare Organizations

http://www.healthleadersmedia.com/content/TEC-90944/Applying-Business-Intelligence-to-the-Needs-of-Healthcare-Organizations.html

http://jonhunt.org/resources/HealthcareAnalytics_eHR_EMR.pdf

What is an Information System? , Dr. Harding http://polaris.umuc.edu/~gharding/isas610/wk1Ch01LectureteGlobalBusinesses.html

Databases, Dr. Harding http://polaris.umuc.edu/~gharding/isas610/wk4ch06Lecturette1Databases.html

Information System Definition, Information System in Global business today, ch.1, pg.16

Management Information System, ISAS 610, Ch. 12, Enhancing Decision Making, pp. 450

Key elements of Organizations, Dr. Harding http://polaris.umuc.edu/~gharding/isas610/wk1Ch01LectureteGlobalBusinesses.html

How business intelligence should work, Kevin Quinn.

http://www.techrepublic.com/whitepapers/how-business-intelligence-should-work-the-connection-between-strategic-analytical-and-operational-initiatives/1129907

Special Report, BI Megatrends. January 2008, David Stodder

http://www.informationweek.com/news/software/bi/showArticle.jhtml?articleID=205602945

Tableau Software, www.tableausoftware.com

Three Tips for Solving the Communications Dilemma

Written by Elizabeth Larson on October 4, 2011. Posted in Articles. 2 Comments on Three Tips for Solving the Communications Dilemma

Recently I talked to a colleague with a communications dilemma. She wondered how she should communicate with her various stakeholder groups. Thinking out loud she pondered, “When I’m with business people, I always try to use business language, including their acronyms, which I’ve gone out of my way to learn. But what about when I’m talking to the technical experts? Should I talk techie to them?” She went on to say, “I write a lot of proposals. I have some stakeholders who let me know right away about typos or if my grammar is not exactly right. I have other stakeholders who have told me that my writing style is too formal and that I shouldn’t use such correct grammar. They feel it’s intimidating and unfriendly.”

As BAs and PMs we know we’re supposed to be good communicators, but what exactly does that mean? We are trained to be aware of others’ communication style. We use our intuition, empathy, and awareness of body language to “read” others. But is that enough? And does that apply equally to our written and our verbal communication? What about the language we use? I have always loved the quote from the poet William Butler Yeats, “Think like a wise [person] but communicate in the language of the people.” Does that mean, however, that when we are talking to someone who misuses the language, that we should match our language to theirs? I don’t think so. Matching the communication style does not necessarily mean mimicking their language. However, we do want a communication style that makes our stakeholders comfortable.

How can we solve this communications dilemma? Here are three tips for both written and verbal communications that can help.

Take the time to keep it simple. We are all aware of the wisdom of keeping it simple, but simple doesn’t mean easy. Simple doesn’t mean careless. It is often harder to keep it simple, because keeping it simple requires thought, precision, and a good command of the language. I find that it takes a great deal of thought to write concisely and say everything I want to in language that all stakeholders will understand.
That same principle of simplicity applies when we paraphrase, or restate what was said in different words while keeping the nature of what was said intact. I think paraphrasing is one of the most difficult skills to master. It requires the ability to take in a lot of information, to synthesize it, to concentrate on what is being said, and at the same time to rework the ideas to make them understandable. It’s tough work!
Be correct without being pretentious. When we use incorrect grammar or when we don’t bother to check our work, we run the risk of being judged poorly, of reducing our credibility, and of not being taken seriously. On the other hand, when we use ornate language and complex sentence structure, we run the risk of losing our audience. I remember taking a multiple choice test in high school where the correct answer was “It is I who am going shopping.” Wow. And of course there’s the famous line from Churchill. Apparently his editors rewrote a sentence to make it grammatically correct, and apparently he responded with the famous line, “This is the sort of bloody nonsense up with which I will not put,” pointing out the ridiculous nature of obscure grammatical rules. In a nutshell, I think we should strive for communications that are both intelligent and clear.
Use language that both technical and business people understand. I have found that when I use technical language with business people, they have a harder time understanding me than if I use business language with technical people. Using business language, then, tends to be more easily understood by all stakeholders. As a project manager working on software development projects, I always encouraged the developers to use business terms, even when the subject was technical in nature. For example, instead of saying DB17, I encouraged the team to talk, even among themselves, about the Price Change database.

Another example I use is that when we need to find out about data business rules, we might walk into a requirements workshop and ask about the cardinality and optionality, but we’d probably get some blank stares. However, we can translate those concepts into questions our SMEs can understand and answer. For example, we might ask if end-users can set up customers who don’t have any accounts. Or what information the end-users need to enter before they can leave the web page. I have always believed that translating technical concepts into business English, while annoying to some team members and technical whizzes, has always been worthwhile. It encourages us to focus on the business need rather than the technical solution.

Finally, let’s look at the intent of the communications. If we all understand each other and what we’re trying to say, then I believe we are communicating effectively, even if our grammar isn’t perfect or we don’t use the right words. And I believe that most stakeholders get that and won’t judge us harshly. However, for those stakeholders who want each “i” dotted, let’s proof our work. It will help build our credibility. The key is to know our stakeholders, but that’s a topic for a different day.

Don’t forget to leave your comments below!

Managing Your Boss

Written by Harry B. Mingail on August 16, 2011. Posted in Articles. 1 Comment on Managing Your Boss

Most business analysts have one. Yet attending to their demands and idiosyncrasies can be nerve-wracking. Wise business analysts engage good boss management strategies. Boss support, guidance, mentoring and influence will be your reward.

After all, bosses are not exalted and invincible gods. They are human beings with special roles and authority as well as the requisite levels of human weaknesses, problems and pressures.

Under these demanding conditions, most boss relationships unfold in two possible directions: the 3Rs Resistance-Resentment-Revenge or the 3 Cs Clarity-Co-operation-Commitment.

The 3R cycle is characterized by ineffective communication. This causes levels of resentment. People expend valuable energies getting even. Such a work environment becomes destructive not only for individuals but for the entire organization.

On the other hand, the 3C cycle begins with people clarifying what is required. People cooperate and commit themselves to excellence. Personal self-esteem and group performance is enhanced.

Assess Leadership Style

Recognize leadership skills inherent in your own boss. This assists you to understand your boss better. You also benefit by becoming a better manager. The more effectively you manage subordinates, the more leverage you will command with your own boss. “To lead, one must follow” … Lau Tzu.

Leader #1: The Press Leader

These leaders pretend to be drill sergeants. Low self-esteem and a strong fear of failure drives them. They are impressed by outward displays of busyness rather than by results. The leader treats people as expeditors who obey orders. They tolerate no mistakes. Trivial details snare their energies and attention. They over-supervise and manage by punishment. Doing so squashes self-esteem amongst the ranks.

How to handle the press leader? Quickly discover on-the-job limits. Determine whether your boss is simply tough or ruthless. The tough leader precisely delegates authority balanced with appropriate responsibility. The ruthless one disregards human factors. If you choose to resist the press leader, do it privately, not within view of colleagues. This way your leader will not lose face.

Support your position with plenty of evidence. Otherwise, you lose.

Leader #2: The Laissez-Faire Leader

This leader abandons staff. These leaders provide little or no support in tough times. They stipulate little of what is expected of employees. They provide virtually no guidance on how to accomplish tasks. While the press leader may hover over an employee’s shoulder, this leader does nothing to train or guide. While the press leader over-manages, the default leader overlooks.

Managing The Laissez-Faire Leader: The individual who is self-motivated and needs little praise will work well under this type of leader. This leader craves facts such as costs, statistics and research findings. Provide these facts and figures for your boss, while at the same time try to stress some human elements. Encourage your boss to clarify exactly what is to be accomplished.

Leader #3: The Participatory Leader

The participatory leader is adept at communication procedures. Under this type of boss, employees are given precise feedback and recognition when deserved. The participatory leader strives to involve employees in the assessment process. He or she is inspirational and innovative. The participatory leader customizes the type and amount of feedback required for each employee.

Managing the participatory leader: The most effective way of dealing with the participatory leader is to feed back the same techniques that he or she uses with subordinates. Keep them informed of what does and does not work. Since this type of leader is interested in results, your opinions will be heeded.

Leader #4: The Develop Leader

This leader goes a step beyond the participatory leader. The develop leader fosters staff self-esteem, autonomy and competence. Techniques for success are isolated and taught to subordinates as the need arises. The develop leader empowers staff and nurtures a feeling of reverence, not in the boss, but in the employees themselves.

There is often a high staff turnover rate for employees of develop leaders. But it is a good one because it is upward. Because this type of leader creates such a high level of competence amongst the ranks, there is always someone to take over when someone moves up.

Both the develop and the participatory leader expect good performance from their subordinates. This expectation is communicated not only verbally but through a trusting working relationship that encourages autonomy.

Weaknesses and strengths exist within us all but being aware of the bosses can help manage the relationship on an on-going basis. Keep the below points in mind –

Boss Weaknesses

Lack of Training: Is your boss a whiz at finance, but uncomfortable dealing with human elements? Few managers score A’s on both task and people-oriented responsibilities.

Unclear purpose: Can your manager clearly define goals? A clearly understood purpose assists everyone to fulfil their roles.

Fear of rocking the boat: Does your boss resort to the familiar while stifling new ideas? Managers must adapt to changing values and needs.

Being a saviour: The boss who insists on expending valuable time and money to keep proven weak people afloat helps nobody. This boss ignores competent staff. At best, this approach postpones the inevitable dismissal day.

Having to be right: Even the most talented executive must be willing to make amends when they have been wrong.

Low compatibility: A manager must be willing and able to create alliances with peers, superiors and subordinates. Compatibility is mandatory in the executive suite.

Demanding agreement: Many bosses find it difficult to accept different points of view. Bosses should seek acceptance and assistance, not agreement.

Confusing efficiency and effectiveness: Efficient workers get things done quickly. Effective staff achieve the right goals. The two should be balanced, with priority going to effectiveness.

Boss Strengths

Causes agreement: Idea exchanges lead to the best possible solution. Everyone’s opinion is welcomed and valued.
Manages with continuity: Issues are discussed at regular intervals. This minimizes surprises and last-minute fire-fighting.
Matching people with work: An effective leader carefully considers not only work experience but personality traits when staffing an assignment.
Understands the job: A good leader will develop trusted, valuable employees who strive to contribute to the organization because they feel needed. The successful leader knows the way, shows the way and goes the way.
Respect feelings: Emotional needs of employees are recognized. Employees are offered a guiding hand when making decisions. They are not simply handed the solution.
Gives employees autonomy: Once a level of trust is attained, the more autonomy an employee can handle, the better the employee and organization will be.
Eliminates Boredom: Allows individuals to adapt the work to suit their needs, as long as the job gets done.
Seeks results, not methods: New methods to improve effectiveness should be sought, but not at the expense of results.
Employs positive feedback, not criticism: Focusing on the positive rather than the negative is a proven technique in affecting a desired change in behaviour. This boss “catches subordinates doing something right.” “A soft answer turneth away wrath” … Proverbs.
Combines co-operation with competition: Organizations, which encourage groups to be simultaneously co-operative and competitive, produce the greatest chances for success.

Follow these steps to keep the boss happy.

Learn what your boss expects and values.
Strive for high-quality results.
Solve as many problems as possible without the help of your boss.
Keep your boss informed.
Be your strongest critic.
Get regular feedback from your boss.
Differ with your boss only in private.
Save money and earn revenue.
Be a good leader yourself.
Promote only valuable ideas.

Your boss is not interested in the storms you encountered, but whether you brought in the ship

Don’t forget to leave your comments below.

Harry B. Mingail combines a Project Management Professional (PMP), Certified Business Analyst Professional (CBAP), Mathematics/Computer Science and Business Administration designations with 25 years of BA, PM and management consulting as well delivery of webinars, workshops, mentoring and keynotes.