Skip to main content

Tag: Learning

Strategy Spotlight: Be Teaming with Success: Using Assessments and Profiling to Understand Yourself and Others

I have received a number of emails regarding a statement I made in one of my previous blogs.

In that particular post, I mentioned the importance of understanding yourself and others through profiling. The exact quote, “you should profile yourself and the people around you” (See article Master These 7 Skills to Become an Excellent Interviewer). So let me explain the importance of profiling and give you some options.

Related Article: Master These 7 Skills to Become an Excellent Interviewer

A project manager and/or business analyst is a leader who must engage people in order to get stuff done. This reality exists whether through identifying business problems or opportunities, evaluating solution alternatives, or planning and implementing projects. Nothing happens unless you can engage people appropriately. Profiling helps.

Three Profiling Rules and Profile Types to Endure

There are a few rules about profiling that you need to internalize. First, it is not about you so leave your ego at the door. Second, it is all about the other person’s communication needs. Third, you need to adapt to the communication needs of the other person.

Generally, there are three kinds of profiles to consider; intelligence quotient (IQ), emotional quotient (EQ) and culture quotient (CQ). EQ has to do with emotional intelligence and is now considered more important than IQ in achieving success in our lives (business, career, and life). Success is dependent on our ability to read people and act appropriately.

Four Attributes of Emotional Quotients (EQ)

Self-Awareness: You are aware of your thoughts and emotions and the impact they have on your behavior. What you think is what you feel, what you feel is how you act and how you act is the results you get (think, feel, act, results).

Self-Management: Can be defined as your ability to manage your feelings and behaviors. It includes your ability to adapt to changing circumstances.

Social Awareness: This is where you engage in understanding other people. In essence your ability to read the situation around you, pick up on social cues and adjust accordingly. It is all about people and group dynamics.

Relationship Management: Emphasis is placed on your ability to develop and maintain good relationships. This could be short-term (for projects), to influence and motivate others, to interact for the purpose of understanding a problem, to manage conflicts, etc. I like to think of this as your ability to get on and get along in life.

Six Tools of the Assessment Trade (there are more)

There are many tools that can be used to develop your understanding of yourself and others. I believe that throughout your career it is important to use several tools in order to develop a self-profile that goes beyond just the standard EQ assessment. It’s important to look at your career and work fit, your career anchors, and of course the standard emotional intelligence profiling options. Here is a list of options to help you build your ability to understand yourself and others so you can improve your professional effectiveness.

DISC Profile: This is a behavioral model that examines individual behaviors in their environment, their styles, and behavioral preferences. Four areas looked at include; Dominance (control, power, and assertiveness), Influence (social situations and communication), Steadiness (patience, persistence, and thoughtfulness), and Conscientiousness (structure and organization). This is a powerful tool for profiling, building teams and relationships.

Self-Management Pro: This one is used to predict management and leadership potential so that organizations can develop their professionals. The tool has been proven effective in predicting performance and retention. I like the way it looks at your profile and style in terms of process and structure, learning, orientation, self-direction and lifestyle management.

Myers-Briggs Type Indicator (MBTI): A personality inventory that measures people in four key areas; how you relate to others (either by extraversion or introversion), how a person takes in information (sensing or intuition), how a person makes decisions (thinking or feeling) and how a person orders their life (judging or perceiving).

Career Anchors: We are all anchored in something. This tool will help you understand your career anchors and other people’s career anchors. Everyone is not anchored in the same things. You and the person you are working with will fall into one of eight categories (autonomy/independence, security/stability, technical/functional, general management, entrepreneurial creativity, service, pure challenge, and lifestyle). Knowing a person’s career anchors tells you a lot about their natural motivation.

Career Fitters: My new favorite profile as I filled this one a few weeks ago and I was surprised how accurate it was. This profile looks at your personality in the workplace and then provides you insight into career options based on your work personality style. It is great for working with teams and individuals to understand fit or even working with other people and their fit to what they are doing. Send me an email if you would like a link.

Coaching Skills Inventory: The coaching skills inventory generates an overall coaching-effectiveness profile. It teaches you how you do in meetings from the opening, communicating, gaining agreement and closing. Don’t let the title fool you as it is not just about coaching. It can be used to improve your meeting performance. Something I found incredibly valuable in identifying my weaknesses and then developing my meeting skills. This is a huge bonus.

Final Thoughts:

The importance of understanding yourself and others continues to grow. I think it has become imperative that the professional step up and take the time to learn how to profile and adapt in order to increase their success. A combination of emotional quotients and career profiling provides valuable insight into the world around you. These profiles are becoming increasingly relevant to organizations and people development, and the ability to solve business problems because they provide a way to understand and assess behaviors, styles, beliefs, values, attitudes and interpersonal skills. All of which impact your ability to do your job.

Over the course of my career I have done a lot of interviews, small group meetings and workshops where understanding the people around me was critical to the initiative success. Sometimes we would profile on-the-fly and other times we would do formal profiling using a combination of tools, one-on-one debriefs and Group to Business Impact Sessions. Something I still do for clients today.

What if the Project Client Won’t Move Forward?

Business analysts – tell me this – have you ever worked with those project clients that you can’t seem to get out of the starting gate?

You seem to be in a perpetual starting mode, but the real project never seems to happen? Have you ever had projects that seemed to take forever to start and maybe never started?

As an independent consultant, I’ve had many clients seem like they were ready to go yesterday on projects…only to find myself six months later still discussing how we might get started. It’s frustrating; it takes time away from other projects we are managing or involved in and caters to clients who may really only be fishing for information from experts with little to no intent of ever starting a project.

Related Article: 5 Reasons You Need a Business Analyst Before Project Kickoff

How do we recognize these situations so we can somehow avoid them the next time they start to show these same signs? Or better yet, how do we help push them along into real projects? Let’s consider some possible concerns.

How can we more easily and quickly recognize these situations as they start to happen?

My quick answer is you don’t recognize it until it’s too late. And by too late I mean until you’ve spent some considerable email and phone time – and for larger, potential projects maybe even face to face time involving expensive travel. Yes, you may blow through a considerable amount of time and money and never get anything out of it. That’s the nature of project negotiation – it happens all the time. But avoiding it is almost impossible.

You don’t want to chase those project opportunities that are clearly outside of your scope of expertise. Your likelihood of success is low anyway. But if it looks like a good match then the ambitious business analyst is going to put their head down and push forward as hard as they can and try to get a project going out of what they have so far. And continuous client promises of a decision by the end of next week, or an agreement after one more discovery call, leaves a deal too close to pass up after you’ve already put weeks or months into trying to finalize the deal.

Suddenly, you look back and six months have passed. If you truly reach that six-month milestone, it’s probably time for the business analyst and project manager just to give up. You can’t turn a potential project customer into something they are not.

You know the saying; “If you love something, let it go…if it was meant to be it will come back to you.”

Is there a way to avoid these types of situations?

Probably not. But it may be that we could ask better questions up front. We never want to sound too pushy, of course. But it’s fair to ask if there is budget approved for this project, if the project is backed by senior management, or if there are high-level requirements mapped out already.

Have they gathered end users and questioned them on the potential project? The bottom line is this; have they really thought this through in terms of need and finances before they came to you or did they come to you fishing for some ideas?

If you ask the right questions, you can find out if they’ve really thought this through, if it’s a project with money and thought behind it or if it’s just in it’s just a concept in its infancy. You may even find out if they have decided if you’re the fit if it does become a project. You might just be one of fifty that was selected to be pinged with an email or phone call to get some information that might help them along in their decision process.

Be careful, however. If you give them a lot of good information, you may become the single source of providing them with planning info that they have no intention of paying for in the long run. I’ve been there. I think I’m in one of those situations right now, but I haven’t quite figured out if that is the case or not…so I’m hanging on.

Can we more easily turn them into real projects?

The quick answer is that you won’t be able to, or that you’ll fail more often than you’ll succeed. You can’t force something that was never really meant to happen. However, if you feel you are close and that the chemistry is fairly good, then the thing that may push it over the line into real project territory is one of two things; 1) drop the proposed price or 2) the addition some interesting service or add-on product. Giving them back some of their proposed dollars or giving something of yourself or offering for free can turn some of those “explorations” that never end into a real project.

Summary / call for input

We think we are in control, but we aren’t. We are the experts and possibly the business analyst is the most expert resource of all on each project. Still, these situations happen and can be so extremely frustrating. Just when we think we are about to get a new project in place and ready to move forward, the customer may throw a new wrench into the process or need more time or need more funding. You can’t force a “yes.” You can maybe negotiate a “yes” by giving more away for free, but at the business analyst and depending on your organization, you may not be able to negotiate too much or make that call. Again, it can be incredibly frustrating. If you are in a position to do some negotiating, then consult with the project manager and team and weigh the options. But be sure to think about the long term, too, not just the short term. And then decide – keep going or give up? That’s about the only amount of control you can have.

How about our readers? Have you been in a position with a project client that seems to be in a holding pattern indefinitely? What did you do to push it toward being a real, viable project? Were you successful?

Requirements in Context Part 8: Derived Data

It’s the job of Business Information Systems to know stuff. They are able to know stuff either because they have been told the stuff or because they have been told how to derive stuff from the stuff they know.

This article is about deriving stuff within the context of detail functional requirements.

Contexts For Derived Data

In parts 5 and 7 of this series we saw three detail requirements contexts that can involve derived data:

  • Interfaces
  • Reports
  • On-Line User Interfaces

There is a fourth context not yet discussed – Internal Processes.

Content Detail for Internal Process Requirements

An internal process is a cross between a report and an input interface. It’s like a report in that it runs at a scheduled time and has selection criteria that finds all of the records it needs to work with. Having been initiated and with the selected records the internal process behaves like an input interface, working its way through those records with the result being new records inserted into the database and/or existing database records updated.

An example of an internal process for a Banking Information System might be “Credit Customer Accounts With Earned Interest.” Scheduled to execute daily, the process would:

  • Find all of the Customer accounts that are due to be paid interest.
  • For each account found
    • Look up the rate of interest that applies to the account type
    • Calculate the amount of interest earned
    • Create a credit transaction for the customer containing this amount
    • Post the transaction (resulting in the account balance being updated with the interest amount)

A detail requirement for the “Earned Interest” internal process would follow the same pattern as for reports and interfaces described in Part 5 – a single detail requirement that names the process and references its details recorded in an Internal Process Spec. The drafting of this requirement either as a User Story or Shall Statement is left as an exercise for the reader (pick your preferred format). Extra credit will be given for including acceptance criteria.

As indicated in the previous articles, the detail requirement does not mention each field involved. Rather the detail, including identifying individual fields involved, is relegated to a template-based specification appropriate each of the context types. In cases where a field represents derived data, a description of the derivation should be included as a comment associated with the field. We will see examples of these below.

Data Derivation Descriptions

I like to think of derived data, and their corresponding descriptions as being one of the following three types:

  • Grown Locally
  • Phone a Friend
  • Build an Ark

Grown Locally – With this type of derivation, the values needed for the derivation can be found amongst the other fields in the spec for the given context. So when you are describing the derivation, you are referencing fields that are listed right there in the spec.

Example 1 – Producing an Invoice, the query has returned all of the line items being included in the report. Each Line Item includes the “Total Amount” for that line. So when it comes time to derive the overall “Invoice Total” field value the necessary items to sum up are all available. If the invoice can involve additional fees or charges, then the derivation would involve them as well.

Given fields called “Line Item Total” and “Shipping Charge” listed in the report spec, the derivation description in the comments field for “Invoice Total” might be:

Sum of Line Item Total values plus Shipping Charge

This description is a verbal version of a mathematical formula. The equivalent mathematical version would look something like this:

Invoice Total = Sum(Line Item Total) + Shipping Charge

In cases where a derivation formula involves lots of fields and/or more complex calculations it can be clearer to use abbreviations:

LIT = Line Item Total, SC = Shipping Charge
Invoice Total = Sum(LIT) + SC

NOTE: I’ve kept the example that uses abbreviations the same as the previous two forms. It would probably not be necessary to resort to this style until the number of fields or the complexity of the formula gets larger. When you encounter these, you’ll recognize the benefit of using both the mathematical form and abbreviations.

Example 2 – Presenting Customer Name on a report or screen as a single field derived by stringing together the locally available non-derived fields Title, First Name and Last Name. The derivation description in the comments field might be one or the other of the following:

Customer Name is a concatenation of Title, First Name and Last Name. E.g. Mr. Fred Smith
Customer Name = Title + [space] + First Name + [space] + Last Name E.g. Mr. Fred Smith

Derivation descriptions should include examples wherever possible. Examples help confirm what the business is wanting and provide guidance for development and testing. Note that both description versions in Example 2 expect there to be spaces between the concatenated fields. The first description didn’t mention anything about spaces, but the included example showed that spaces were part of the derived result. The second description indicated spaces explicitly. Even so, an example is worth including.

Both Example 1 and 2 above involve simple formulas describing how to derive a field from existing data using arithmetic operators or via string manipulation. Derivations can also involve logical operators such as greater than, equal to and less than either as simple pairs or combined with And, Or and Not. The following variation on Example 2 involves a single condition. The additional fields are assumed to be ‘grown locally’ as well:

Example 3 – Presenting either a Person Name or an Organisation Name depending on Customer Type:

If Customer Type is equal to “Person” then Customer Name is a concatenation of Title, First Name and Last Name
Otherwise, Customer Name is Organisation Name. E.g. ‘Starbucks’, ‘Mr. Fred Smith’

Phone a Friend – This type of derivation involves one or more values that are not amongst the fields in the context. They need to be sourced from the information system’s database.

Example – Grocery item purchases being captured using an on-line POS terminal. Scanning the barcode of each item identifies the product but the “Current Unit Price” needs to be looked up. The derivation description in the comment for this field might be:

Use the product’s BarCode and the current date/time to find the Product’s Current Unit Price

Note that his description is very ‘what, not how.’ No mention is made of what table contains the field that will have the value needed. Those details should be left to the solution designers. The derivation description is best left to what the business knows at the time the derived value is needed. If it turns out that additional details are required to find a result, then the SME should provide the correct information for the BA to include in the description.

Data derivations can be a mixture of Grown Locally and Phone a Friend. If a derivation formula involves one or more fields that require lookup, then the description might best be split into multiple steps. The Phone a Friend steps should be described first so that the values become available. They can then be used as if they were ‘local’ in the remainder of the derivation.

Build an Ark – When derivations go much beyond a simple formula, a small number of database lookups and/or conditions the form of the derivation is called an algorithm. The comment field of a detail requirement spec is not an appropriate place to describe an algorithm. It really needs its own separate specification [template] and its own [single] requirement.

Content Detail For Algorithm Requirements

Algorithms will typically have a business activity name such as “Determine Price” or “Determine Eligibility”. This activity would very likely appear as its own ‘box’ in at least one business workflow. Descriptions of algorithms fall into the category of ‘A picture is worth a thousand words.’ In this case, that means providing something like a UML Activity diagram. Those types of diagrams are designed to show sequences of steps and branches based on decision points (i.e. conditions). The pre-UML name for an Activity diagram is “Flow Chart.” The diagram (and supporting text and definition of fields used) represents the details of the functional requirement.

Like the contexts discussed previously, a single requirement should be used to represent the detail. An example based on our ‘pricing’ activity would be as follows:

User Story Format:

As a Customer, I want my contracted rates used when pricing purchases because those rates are legally binding during the term of my contract.

Shall Statement Format:

The system shall use the currently contracted rates for a customer when calculating the price for purchases made by that customer.

Both requirements should include acceptance criteria:

Acceptance Criteria

  • Given the current contracted rates for a customer
  • When the customer purchases a product
  • Then the price charged for that product is the result of those rates being applied to the “Customer Pricing” algorithm described in Appendix C.

The activity diagram and accompanying description are produced by the BA in conjunction with the SME that understands the algorithm. Some of the fields involved will be ‘locally grown’ and some will involve ‘phone a friend’.

Requirements In Context – Just Know It

This series has been about business information systems and how it is their responsibility to know what users need to know to support their business processes and activities. What the system ultimately knows is field-level detail. This detail is sourced from input interfaces, on-line interfaces, internal processes, and algorithms. Providing that detail to users and other systems is through reports, output interfaces, and on-line user interfaces. Detail requirements, at the end of the day, is about field level details in context.

The next and final article will summarise the key ‘take-away’ points from the series. Following that, there will be a quiz.

Strategy Spotlight: 6 Strategic Spotlight Terms You Should Know

Recently I wrote about the importance of communications and having a common stakeholder language.

From a strategy spotlight perspective this is extremely important. Definitions and a common language help the business analyst keep people on track so they move things forward. Often I have to tell my stakeholders what the terms mean in the context we are using them in and that they cannot change the definition. This approach helps move stakeholders forward. In the strategic facilitation this is a valuable approach. Even if you are not doing strategic facilitation or planning, as a business analyst or project manager you need to know the key terms to align your work and project initiatives.

Related Article: 8 Ideas for Creating a Common Language and Communication Plan

Here are six strategic analysis, planning and implementation terms I often give to clients to ensure that we are all speaking the same language and our work aligns with the over arching business requirements and stakeholders needs.

Strategy Agenda Item is a high level plan of action item designed to achieve a vision. Since strategic planning is a component of the business planning that is to be done before you take tactical action it is imperative that there is a clear understanding of the strategic agenda items as they provide focus. Often rather than focusing on internal operational issues, a strategic focus means addressing and solving business problems through the effective use of existing resources. As strategic initiatives are defined resource usage is analyzed.

Related Article: 5 Questions Business Analysts Should Have in Their Question Inventory

Strategic Initiatives should represent the most significant line of business or cross line of business projects that are planned to improve the business in some way with consideration for the four key business impact zones. In this part of strategic planning phase the team is deciding the essential focus and key initiatives that must be met to achieve the strategic agenda items. Depending on the size of your organization these will become enterprise, program or project initiatives. They can be very strategic or tactical based on your organization’s size, structure and present culture. At the initiative level the way you define success in the attainment of our objectives should be clarified, the speed and distance of action determined and the critical success factors defined. This takes a while to do.

Business and Initiative Champions are individuals that go beyond their operative responsibilities. As defined here, they are individuals trying to influence strategic issues larger than their own immediate operational responsibilities. They take the initiative and accept responsibility and accountability for it. The potential ways and objectives of championing cover the whole process of strategy: the formation of the content of strategy as well as the process of implementing strategic contents.

If the focus is more of being an initiative champion then that person should bring discipline and rigour to planning and execution of an initiative ensuring the timing and achievement of milestones and deliverables are agreed upon and managed. They will need to tie investment in strategic items and strategic initiative to specific and measurable outcomes and enable issues to be addressed and resolved proactively, before they jeopardize outcomes.

A champion can be used more specifically to refer to a senior manager who champions the project, ensures that it is properly resourced and uses their influence to overcome barriers for the team.

Measurable Outcomes are the measurable results of the implemented objectives and must be defined in measurable terms. Measurements are essential for understanding what is happening in your business–what gets measured gets done. In a business environment, measurements come in many forms and include hard, soft, lagging and leading indicators.

Lagging indicators are used to measure performance and allow the leadership team to track how things are going. Because output (performance) is always easier to measure by assessing whether your goals were achieved, lagging indicators are backward-focused or “trailing”—they measure performance already captured. Just about anything you wish to monitor will have lagging indicators. Leading indicators are precursors to the direction something is going. Because leading indicators come before a trend, they are considered business drivers. Identifying specific, focused leading indicators should be a part of each business’s strategic planning and decision-making process.

Related Article: Lagging vs. Leading Business Indicators – Do you know the difference?

You can pre-determine or reverse engineer measurable outcomes by either using the SMART and/or CAR principle. As part of the measurable outcome determination always consider key stakeholders.

Key Elements are the big things that need to be done in order to be successful. They are the big buckets of work. The key to creating key elements is to understand the scope of work at a high level and to be able to state them clearly. A scope of work sets forth requirements for performance of work to achieve strategic and project objectives. The scope of work must be clear, accurate and complete. It needs to be understood by a wide audience. Defining key elements is part art and science and takes a while to master.

Milestone is one of a series of numbered markers placed along a road. Within the framework of strategic planning, a milestone is a special event that receives special attention. It is often falsely put at the end of a stage to mark the completion of a work package or phase. Milestones should be put before the end of a phase so that corrective actions can be taken. In addition to signalling the completion of a key deliverable, a milestone may also signify an important decision, which outlines or affects the future of an initiative or project. In this sense, a milestone not only signifies distance traveled (key stages in a project) but also indicates direction of travel since key decisions made at milestones may alter the route pre-determine in the various plans (strategic, tactical or operational).

Final Thoughts

Whether you are working on a top-down, bottom-up or mid-level initiatives having clear definition of these terms will help you. It is very difficult to walk into a room and write a list of terms on a white board and ask people to define them. You will spend a lot of time on an activity that should be done prior to meeting. I believe the professional provides the words and defines the terms that will be used. I have provided variations of these terms when working with clients to align their thinking, to build or interpret roadmaps and plans already created and to ensure stakeholders had a common language. I invite you to adapt them for your own use. Good luck.

Always
Do your best,
Invest in the success of others,
Make your journey count.
Richard
Article adapted from SET for Success, Chapter 15, by Richard Lannon

Why a Business Analysis Certification Is Worth your Time

Early in my career I didn’t understand the value of credentials. I thought that if I did good work, I would get promoted and that passing some silly exam didn’t prove anything.

Over the years my opinion has changed completely. I now understand the discipline required to earn a certification and the value that comes with knowing an industry standard way of operating. I’ve just finished writing a study guide for PMI®’s business analysis certification, the PMI-PBA®. In 2012 I wrote a similar study guide for IIBA®’s CBAP® and CCBA® certifications. After spending over 1000 hours writing about these certifications, I thought I’d share my conclusions.

I have changed my thinking about certifications gradually over the last ten years. Part of the reason is the overwhelming scientific evidence about how human beings learn.

Related Article: Is a Multi-tiered Certification Program the Way to Go?

I have been working in learning and development organizations for 25 years. I have been frustrated by how many students attend a class but don’t retain the information or put their new skills to use. I have continually improved the way I present information to students, realizing that learning doesn’t happen in a couple of days. It takes reinforcement over time. It requires the learner to be forced to recall and demonstrate the new skills.

It is now indisputable that testing is one of the best ways to make sure that humans learn new materials. It turns out that our brains learn best by being forced to recall things that we have learned. The more we recall, practice, reinforce learning, the more likely we will retain it, and these skills will become second nature to us.

In addition to the neuroscience, which proves that testing is a strong learning tool, I have experienced the preparation and study activities necessary to pass a certification exam. In the past 10 years, I have taken four certification exams! Each one required a different level of study based on my work experience. In each case, I started out thinking that I knew everything I needed to know about the topic but each time I was humbled by how much more knowledge and skills were available to me. I was exposed to new ways of thinking, new techniques, and most importantly, I reinforced the things I had already learned and learned them at a deeper level.

Preparing for a difficult exam requires a commitment to achieve, a plan for accomplishing your goal, a willingness to take a risk, and diligence in sticking to the milestones you set. It requires you step outside your comfort zone and push yourself in a new direction. All of these requirements are characteristics of successful business analysts. We love to learn new things, solve complex problems, and conquer tough challenges. Passing a tough exam builds your confidence in taking on new challenges. Earning a certification demonstrates your competence and enriches your personal value.

Taking the exam is a small part of the certification process. A strong certification program requires you to learn the breadth and depth of a body of work which few people would learn in their day to day work. Learning about things you have not yet experienced prepares you for more challenging assignments. Forcing yourself to recall key ideas and concepts, cements them into your neurons. In addition, a certifying organization requires you to keep the learning alive while adding new knowledge through continuing education requirements.

The business analysis certification programs offered by IIBA and PMI continue to rely more and more on situational questions rather than just asking about terms and definitions. These scenarios allow you to demonstrate that you make good decisions and choose the appropriate analysis techniques for each situation.

In addition to the benefits of learning and reinforcing your skills, earning a certification shows the world that you can commit to a tough goal and achieve it. It gives you confidence in your knowledge and strengthens your ability to work effectively. Maintaining certification forces you to keep up with current trends and give back to the profession. You become a mentor to others who desire to earn the certification, and you become a leader in your profession.

As a profession, it is in all of our best interests to have strong certifications. None of us would ever consider seeing a doctor or lawyer who wasn’t certified or licensed. In many professions, these tests are considered entry level requirements. A lawyer is not allowed to practice law in America without first passing the state bar exam. A nurse cannot see patients until he has received his license. If we want business analysis work to be valued and rewarded, we need to hold ourselves to a very high standard. A certification program provides the basis for that standard.

When you started reading this article you may have hoped that I would tell you which business analysis certification to earn. That is up to you. I am interested increasing awareness of the value of business analysis work and support any rigorous certification program which will advance our profession. Choosing the best program for you is another learning challenge which I encourage you to undertake!