Tag: Learning

What if the Project Client Won’t Move Forward?

Written by Brad Egeland on September 7, 2016. Posted in Articles. 1 Comment on 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.

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

Written by Dan Tasker on August 9, 2016. Posted in Articles.

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

Written by Richard Lannon on August 3, 2016. Posted in Articles.

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.

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.

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.

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

Written by Barbara Carkenord on August 3, 2016. Posted in Articles.

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.

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!

Your Next Business Analyst Will Be a Robot

Written by Kupe Kupersmith on July 27, 2016. Posted in Articles.

The advancement in artificial intelligence is mind blowing. So much so that teaching robots problem-solving skills is kicking into high gear.

I recently went to a science museum with my family, and one of the exhibits showed that robots are learning problem-solving skills. If you know about and/or believe in Singularity, this is no surprise. You can learn more about singularity here. For a quick reference, I want to share this definition. “The technological singularity is the hypothesis that accelerating progress in technologies will cause a runaway effect wherein artificial intelligence will exceed human intellectual capacity and control, thus radically changing or even ending civilization in an event called the singularity.” In Time magazine about 5 years ago, there was an article that predicted singularity would hit in 2045.

Related Article: Stop Calling Yourself the Bridge

When I read the sign at the museum stating robots are learning problem-solving skills it made me think about the impact to the business analysis profession. Problem-solving is what business analysis professionals do. They are problem solvers. Which led me to think the next generation BA will be a robot. I know most people reading this article will most likely be retired by 2045, so you don’t have to worry about your business analysis role. You may have to worry about how this impacts retirement, but you’ll have to talk to your financial advisor about that one. This took me down a path thinking about how technology is disrupting the BA profession. I landed on the thought that if robots can be BAs in 30 years, then humans half way around the world can be your next BA hire right now. Technology may not be sophisticated enough for a robot to take your job, but it is sophisticated enough to give companies the ability to hire a BA anywhere in the world.

Before I get into what you can do what this means to you and what you can do about it, I want to blow away some myths about having remote BAs.

Distance: I keep hearing people say in the US that the BA role won’t be moved offshore. Well, too late, it already is. The companies I work with have BAs everywhere. I predict the number will grow. And I am not just talking about India or China. Why can’t your next BA peer be from the UK, New Zealand, or Ukraine? Why can’t the next BA on your team be from Los Angeles even though your company is in Des Moines?
Time Zones: How can you possibly have a BA work in New Zealand if the business stakeholders are in the US? The time difference is too great, right? Not too worry. My father worked nights for as long as I can remember. People will work non-9 to 5 jobs if it suits their lifestyle.
Language Barriers: Language barriers will become less and less of an issue every year. When I was in primary school, we started learning a second language in middle school. Now my kids are learning Spanish when they are 5. Younger generations are being brought up in a global world and are being prepared.

Now that I took care of that, you can look at this new reality in two ways. You can see it as a challenge and the fact that you will be vying for a job not only from people in your city but from around the world. Or, you can look at it as an opportunity. No matter where you are, you can apply for jobs around the world. Regardless of the way you look at it, there are things you can do to prove your value to any company.

I have written about valuable skills or characteristics before so I won’t repeat those here. If you have not read my blog post, The Four Chords of Great Business Analysts, please check it out.

For other characteristics to focus on, take a look at an article my buddy Hans Eckman shared from Fast Company, 4 Habits of Employees You Shouldn’t Wait to Promote. Get in the habit.

Oh, but there’s more. Robots may be able to be better problem solvers in the near future. Though, being a good problem solver does not help if you first don’t know what problem you are trying to solve. What good is it if you solve a problem that no one cares about? You need to start or continue to be laser focused on ensuring there is clarity and shared understanding of the problem or opportunity your team is working towards.

Next, you need to focus on remote communication and collaboration. Get really good at this. A recent survey by Meeting Professionals International shows that virtual meetings are expected to grow at twice the rate as live meetings. This is everything from large company meetings to one on one meetings. A large part of your role is to facilitate decisions. The people you are helping make decisions are not always sitting next to you.

Let’s face it; the barriers are broken. Technology has caught up to people’s desire to connect with others around the world. Organizations have options. I can easily connect with friends and colleagues in the UK, Spain, New Zealand, Australia, South Africa, Argentina, and so on. Organizations no longer need to hire someone that lives a commutable distance from an office. There are 2 key things you should focus on as it relates to remote communication and collaboration. One, you have to learn how to connect on a personal level with people in a remote world. This takes some work. In an office, you do this without even thinking. You see someone getting a drink, and small talk ensues. You see them at lunch, on the way to a meeting, or walking into the office and you can connect with little effort. You usually don’t have to make time to connect with them. In a virtual world, you need to schedule it. Work in time during your day to call someone, text someone, chat with someone just to say hello.

Next, you need to improve your virtual etiquette. When you are face to face with someone, you can eat and drink. When you do this on the phone, the noises that are heard on the other end of the phone are not pleasant. If you are eating while you are on a phone call, it’s like someone having their ear to your mouth as you are chewing. It’s rude and sounds gross! If you are a “slurper” when you drink, don’t drink while on the phone. And have you ever filled up a water glass from a water cooler or refrigerator while on the phone? Have someone try it and tell me what that sounds like. I’d rather you eat on the phone!

Technology will continue to change how you live and work. Will robots be the next generation BAs? Maybe. Until then, work on adding value to your organization regardless of where you live or where your team is located.

Virtually yours,

Kupe