Tag: Success

Strategy Spotlight: Catapult the Organization Forward: Discover a CEO’s Thinking

Written by Richard Lannon on July 6, 2016. Posted in Articles. 2 Comments on Strategy Spotlight: Catapult the Organization Forward: Discover a CEO’s Thinking

I was interviewing a CEO of a successful technology product and service company. We were discussing what made the company successful and also their challenges. He openly spoke of the way they approach business growth and their culture with an emphasis on people – both internal and external stakeholder relationships.

Here are the things that were on the CEO’s mind and the commitments they made. I suspect some of these are on your leaders’ minds and you should know them if you want to participate in your company’s success.

Business Growth

When we started talking about business growth I asked the CEO to define what this meant to his company. It was clearly stated that they measured business growth two ways; by top line sales and bottom line results. From an SBA’s (strategic business analyst) perspective this helps tell you where you can have an impact. For example, if your focus is on cost reduction then you get to impact the bottom line through process improvements or other cost reduction measures.

Acquisition

One part of the approach to business growth for this CEO was through acquisition. The acquisition strategy was about finding complementary products and services that were within the business’s ability to acquire that fit with the culture of the organization. There was a huge emphasis placed on people and culture because acquiring another business that did not fit made no sense to this CEO. The reason was simple; wrong culture and wrong fit mean conflict and negative business impact.

So for this company, if the BA is part of a team evaluating acquisition. they would need to know the parameters of analysis using a combination for financial, human resource and risk management approaches to help determine if a move forward is a good idea. This could apply internally as well as when looking at department adjustments. Not to mention if the company succeeded in acquiring another organization, the BA would need to document all the cultural changes, process shifts and adjustments that need to be made. The BA should be part of the success of this approach.

Organic Growth

The organic growth is a portion of growth that applies to increased output, customer base expansion, new product development, innovation, or the geographic placement of your company to serve a clientele. This CEO explained that this is something they can do at a relative consistent annual rate given the nature of their business. For example, a 5 percent annual growth rate per year would be consistent.

But with a little creative development, they could create a revenue pop in their business. The example provided was when a group of business analysts had the idea of recycling metal from old equipment and selling to recycling companies. It turned out to be a small but doable branch of their business done by a couple of people who cared about the environment, took the time to identify the requirements, recommend solutions and help make it happen.

Three-Legged Stool Analogy

This analogy has been around for a long time and is sometimes referred to as the Three-Legged Strategy. When this CEO and I started to discuss this business approach we had a good laugh as we both understood that the Three-Legged Strategy applies to a lot of things. But our focus is the CEO’s perspective. In this case, we talked about customer service, product sales, and maintenance agreements.

They placed a lot of emphasis on training their people to do three things. First, making sure they are solving the customer’s problem no matter what. Second, asking their customers who else should they be speaking to in their company that could also use their services? Third, the simple question, how can we help? All three of these things helped build the business through relationship building and can be part of the external and internal culture of the business.

Their product line was twofold, soft consumables and hard products. Their business growth starts first with customer consumable products. This particular technology company sold customer products that customers would consume on a regular basis, creating a regular cash flow. The consumable products helped the company create a wedge in their customer’s business, opening the door to other opportunities. Think an inch wide and a mile deep. Once they opened the door, they could sell other products.

Their hard products, he felt, were things they could sell once due to the cost. Generally, it would be a capital purchase by a client. They are always looking to sell their hard products, but the real cash flow is in the maintenance agreements to service the equipment. So the emphasis was placed on ways to maintain these contracts and to find additional offerings related to this service. This way they were focused on value services. Their BAs helped define the service and maintenance programs through analysis of the business intelligence data.

There are many lessons learned here relating to the Three-Legged Stool approach. You can see that their culture is a customer focused environment where making sure that the needs of the customer are completely understood and solutions were forthcoming. The culture also reflected that they thought out where their revenue streams were and they emphasized actions towards supporting that area. From an internal perspective, I could see services of an IT department (or any department) following a similar approach for their internal clients. It just needs to be defined.

People and Culture

This was the final piece of the puzzle for this CEO. Not necessarily the last. It just happened we agreed at the start of our discussion to follow a certain flow.

Their culture, he felt, was one of the most important parts of the business success. They were always having discussions on how to improve that part of the business. He was proud to tell me of the $250 annually that each employee gets to give to charity and the company match on top of that and the weekly call out sessions where employees complimented their peers on the work they did. Basically creating a culture where people are engaged and work together to solve problems. But the big word was FIT. People they hired needed to fit with the organization and live the business values. As we reviewed the values, I had the CEO provide examples of what living the values looked liked. Given the nature of the project we were about to embark on this was important to know. Overall this company wanted a culture of trust. Something a BA can learn to do when working with people using the formula; like you, know you, and trust you and I will work with you. But maybe that is another blog on how to build a culture of trust.

Final Thought

As I share this blog and the interview that I did with this CEO I can’t but help think about what I found out. This was a reconnaissance mission to understand the business, the issues, the driving forces and risks. I did get what I needed. This important conversation provided me insight into what was on the CEO’s mind, the leadership commitments of the organization and the lessons learned. I got to ask all sorts of questions related to the business to gain perspective and thinking. This provided valuable information to help define the future, analyze commitments and implement solutions.
As a strategic business analyst, I believe that information and business intelligence data can be used to help business’ achieve its goals and objectives, to analyze aspects of the business to solve problems and provide solutions that fundamentally will help catapult the organization forward. It is important to discover what is on the minds of the CEO. Hopefully, you do too.

Remember to:

Do your best,

Invest in the success of others,

Make your journey count,

Richard

6 Things the Business Analyst Needs to Know at the Start of the Project

Written by Brad Egeland on July 5, 2016. Posted in Articles.

The skilled, experienced technical business analyst plays a critical role on the project as the main liaison between the project manager and the technical project team members. Not only that, they are often the “interpreter” for the project customer so what they need to be ready for at the beginning of the project is both critical and varied.

I’ve outlined here what I feel are the 6 most critical things that the business analyst needs to know or find out at the beginning of each technical project. Not always in detail – that may not be possible. But at least in as much detail as is possible. Let’s examine and discuss.

Related Article: 5 Things Your Project Customer Assumes You Know

Is the tech team ready?

This can mean a lot of things, but what I’m focusing on is this; is the team fully assigned and ready to go when needed?

I realize that this is more the call of the project manager as it is usually that individual’s responsibility to see to it that their team is assigned and ready when needed. But since the business analyst’s key role is to liaison with that team, then they are also involved in that process. The business analyst needs to assist the project manager in making sure that the right team members are available when needed on the project. Preferably not too early but certainly not too late.

Are they technically equipped for this engagement?

The technical project is going to need a particular mix of technical talent to get the job done. As the key tech liaison with the technical project team, the project manager is going to rely heavily on the business analyst’s assessment of the technical capabilities of the assigned project tech team. Do we have the right talent? Do they understand the chosen technology? Does anyone on the team need training to get up to speed? The business analyst needs to assess this and aid the project manager in making these things happen so that the project can move forward.

What state are the requirements in right now?

How well are the business processes and project requirements defined coming into the engagement? Many clients will come into an engagement saying they’ve already defined the requirements – hoping to keep costs low. However, 99.9% of the time you’ll find that they are way off in their assessment of requirements “completeness.” Requirements need to be detailed, complex, and very complete. They are basically the basis for all work going forward. The project manager needs to assess the requirements status and plan the project schedule accordingly, but the technical business analyst will be able to give a much better indication of the state of the requirements and how much more effort will likely be needed to get the requirements fully documented and signed off.

Does the customer have training needs?

It’s a technical implementation and requirements need to be completed with the customer’s input and eventually the customer will need to be leading the way in user acceptance testing. Is there any training – on the technology being implemented or on the customer product that is being configured and implemented – that the project client needs in order to complete the business process review and the requirements definition process successfully? After all, no client can really help the delivery team document requirements if they don’t understand the solution. I’ve found on many occasions that customer training is needed and that changes the project budget and timeline. But it is far better to assess that and make that correction up front rather than later in the project.

Do we likely have the competence to implement the necessary technical solution?

Can the team pull this project off technically? Can the organization? Sometimes a project is just not the right fit, no matter what a sales or account manager who signed the deal says. And the best time to make that call – rather than fail miserably – is at the beginning of the project before any real work starts and any real budget gets chewed up. Sometimes it’s just a tight fit, and some training may need to happen. That’s ok as long as it doesn’t hurt the timeline and the delivery organization takes on that cost if it wasn’t in the original scope of the project. However, sometimes the fit is never going to happen, and that tough call must be made. Once this is realized, talk it over with sales and senior management before throwing in the towel as you want to not only do it right, you want to make sure you’ve exhausted all options before you raise the white flag and surrender. Let senior management make that call and break the news to the customer…they approved the project in the first place.

Does the schedule seem doable? Most schedules are pretty tight. And after an early assessment of the project, the team, any training needs and the technology needed for the solution, the business analyst should be able to make a fairly reasonable – and accurate – call as to whether or not the initial project schedule seems doable. What you need to know from the outset is this; can you win on this project with this schedule – and with this budget? Is it possible or will it be impossible? You may not be able to make that call, but you likely can once you know the above information. At least with some reasonable degree of confidence. If you need more time for the project, the best time to negotiate for that is at the beginning. Later on, it will just look like you’re failing.

Summary / call for input

I’m not saying the business analyst needs to know everything…just like there is no way the project manager can definitely say everything is in order on the project at any given time. However, this list of six key project elements are usually well within the technical business analyst’s knowledge base, and they can make at least a good call on where the delivery team stands on its ability to implement the right solution for the project client. And really, that is what we need to know before we get started because it will affect everything going forward -the timeline, the budget, etc.

What about our readers? What would you add to this list? What would you change about it? Business analysts, what do you see that is missing or that you don’t agree with? Please respond and discuss.

21st Century BA: How to Become a Business Technologist

Written by Kathleen B. Hass, PMP on June 30, 2016. Posted in Articles. 1 Comment on 21st Century BA: How to Become a Business Technologist

In the 21st century, all businesses are technology companies. To survive in the global economy, indeed to thrive, world-class, agile and flexible technology is a necessity.

Without it, organizations cannot cope with the ever-changing competitive environment. Competition is fierce, and an organization’s competitive advantage is always at risk. In addition, the business environment is stunningly complex. Innovation is a precondition to survival. Technology advances are coming fast and furiously. Organizations are struggling to find the talent needed to drive changes to the business and the technology to achieve and sustain competitive advantage.

WE NEED TO CHANGE OUR PERSPECTIVE

The business analysis discipline needs to elevate its thinking, discarding the notion that requirements management is the most important task at hand. That is a very narrow, and frankly doomed view of the scope of business analysis. As enterprise BAs, striving to fill the role of Business Technologists, we are adopting a core enterprise perspective that is driven by the need for business/technology investments to create optimal business benefits in terms of value to customers and wealth to the bottom line.

WE NEED A HOLISTIC VIEW OF THE BUSINESS AND THE TECHNOLOGY

The effective Enterprise BA/Business Technologist thinks big. Thinks strategically. Thinks holistically. Thinks about the customer. Understands that the business and technology components of the organization are part of an ecosystem that is always changing and adapting to variations in the competitive environment and transformations in technology, resulting in requisite changes to business processes, technology, products, and services. While there is no technology that is the silver bullet, we continue to seek out technical products and technical managers to solve all of our problems.

There is no single silver bullet. It’s about being able to identify technologies, understand their implications, combine them in an effective way, and make intelligent decisions in employing them, creating a set of operational processes and organizational structures to surround them, which is a much harder thing than simply investing in one technology versus another.

… We need technologists who understand more in the way of the economic analysis and business strategy. I would also suggest we need technologists who are more integrative problem solvers, which is to say we need technologists who can solve problems across multiple technology domains, and across business and technology domains.

James Kaplan, Principal at McKinsey&Companyⁱ

WE NEED TO GROW UP FAST

An IBM CEO study as long ago as 2010 identified complexity as the biggest challenge, and creativity as the most important skill that is needed to understand and manage complexityⁱⁱ. They went on to say, they have not groomed creative leaders from within, and they can’t find the talent they need through traditional staffing activities. Conventional project roles are changing. The EBA focus is now on strategy, innovation, and value vs. requirements management. The PM focus is now on complexity management vs. project management. However, companies can’t find these types of BAs/PMs – critical thinkers with the ability to:

Adapt, invent, and re-invent
Collaborate, create, and innovate
Leverage complexity to compete.

The business analysis discipline, and therefore the effective business technologist, needs to quickly attain breakthrough skills and competencies – en masse. The need is urgent. Realizing that there is so much innovation in technology today, no organization can know all about the different technology domains that are emerging. Therefore, creativity, problem solving and integration skills become much more important that any specific knowledge about a technical domain such as cyber cybersecurity, cloud computing, or big data. To fill the void, organizations that rely heavily on technology such as banks, insurance companies, and healthcare companies are starting to recruit from within and from outside in the high-tech industry. They are seeking out individuals with a broad set of skills, individuals who have the ability to span business and technology domains, who have experience in integrative problem solving.

Staffing and career development operatives are responding to the need. Companies are seeking out internal and external managers and high performers who are willing to move between different parts of an IT organization as they progress. Some business managers are also moving from the business into selected roles in technology organizations in order to infuse more business acumen into the IT management staff. We need innovation in the world of training for business and IT professionals. Instead of focusing on technical disciplines, Kaplan urges us to foster what he calls first-principles technology problem solving or cross-domain integrative-technology problem solvingⁱⁱⁱ.

ELEVATE YOUR PROFESSIONAL DEVELOPMENT APPROACH

For the individual BA who is looking to elevate their career and status in their organizations, it’s time to modernize your career development approach. Get your hands around a new attitude about your professional development. Build strategy-focused, value-based thinking into your advancement plans.

SEEK OUT NEW ROLES

21st Century EBAs/BTs are bold and courageous. They search for new roles and new challenges to broaden and deepen their experience, knowledge, and expertise. They put themselves in positions with high visibility where the action is. They thrive when working collaboratively with other experts in uncertainty and ambiguity. People in the business and in IT seek them out, asking for them to be on their teams.

LEAD THROUGH CONNECTIONS

The 21st Century is all about connections. In the global world of business complexity, it takes a high functioning team of experts to negotiate the business and technical complexities. So, perhaps your most critical capability is to bring together a group of experts (first get the right people in the room!), and then create an environment where it is safe to experiment, suggest off-the-wall ideas, challenge and build on each other’s ideas; then rapidly test ideas to determine viability^iv.

WHAT DOES ALL THIS MEAN TO THOSE AT THE TOP OF THE BA FOOD CHAIN?

There are many things you can do to accelerate your transition to an enterprise, strategically focused business technologist. Review the suggestions in this article. Get yourself out there. Promote yourself and your project successes.

The next few articles will explore other roles for the enterprise BA, as well as business and technical domains that are undergoing significant transformations.

i Becoming a Better Business Technologist, May 2016. McKinsey and Company. Online at http://www.mckinsey.com/business-functions/business-technology/our-insights/becoming-a-better-business-technologist.
ii Capitalizing on Complexity, Insights from the 2010 IBM Global CEO Study. Online at: http://www-935.ibm.com/services/us/ceo/ceostudy2010/multimedia.html
iii Becoming a Better Business Technologist, May 2016. McKinsey and Company. Online at http://www.mckinsey.com/business-functions/business-technology/our-insights/becoming-a-better-business-technologist.
iv Leading Through Connections, Insights from the 2012 IBM Global CEO Study (www.ibm.com/services/us/en/c-suite/ceostudy2012/‎

Requirements in Context Part 5: Detail Requirements for Build or Buy

Written by Dan Tasker on June 29, 2016. Posted in Articles. 1 Comment on Requirements in Context Part 5: Detail Requirements for Build or Buy

The previous article in this series was about keeping the content of high-level requirements (HLRs) at a high level. This article is about the content of detail requirements containing the appropriate amount of detail. We start with a discussion of four delivery contexts, two involving building the solution in-house and two involving purchasing solutions. Examples of requirements are presented using two forms – User Stories and traditional Shall statements. But regardless of form, at the end of the day, content is king.

Build or Buy Contexts

The availability of subject matter experts (SMEs) is a critical factor in sourcing content for detail requirements. For the purpose of this article, we will assume that such people are available. Of equal importance to this deliverable is the consumer of these requirements – those responsible for delivering (i.e. designing, developing and testing) the solution based on the detail. Consider the following delivery contexts:

Build – In-house with embedded SME (e.g. full Agile)
Build – In-house without embedded SME (e.g. Agile-like, Waterfall)
Buy – a custom-built solution (outsourced development)
Buy – a package solution (with optional customization)

NOTE: The Build/Buy decision process itself is out of scope of these articles.

Build – In-house With Embedded SME

What could be better than having the source of detail requirements, an SME, as a full-time member of the development team? Not only that but working on a business information system that can be implemented bit by bit. Personally, I have only experienced Agile-like development. But based on reports from colleagues there are organizations where these conditions exist.

In full Agile environments, whether user stories eliminate the need for detail requirements or they are just considered to be an improved form of requirements, each user story still needs to include content that drives development and guides testing on the way to ‘done.’ From a requirements perspective, the real improvement is that development does not need to wait for a full set of requirements before work begins. Also, the delivery of results into production occurs not long after the requirement has been expressed.

Full marks to this delivery context and the Agile user story form that drives it. But developing and testing has to involve the complete content of what is wanted, so ultimately that content needs to be recorded somewhere (see examples below).

In-house Build Without Embedded SME

I am fresh off a project that utilized Agile-like development. We were given traditional business requirements. Some were high-level, others low-level-ish. As a BA, my role in one of the Scrum teams was ‘pseudo’ product owner. It was my job to interpret selected requirements and write the corresponding user stories and acceptance criteria. Where a requirement was unclear or did not contain sufficient detail, it was necessary to go back to the business requesting clarification.

Besides the problem with requirement content, the overall project was not suited to incremental implementation. At the end of each sprint, teams were able to demonstrate the results of completed stories, but these elements needed to wait many months for a major release of the system.

Functionality being delivered in each major release had to undergo both integration testing and user acceptance testing (UAT). Acceptance criteria from the user stories were of some use to the broader testing efforts, but end-to-end tests had to be developed separately. And because the business users had not been involved with the user stories, they had to come up with their own UAT test cases.

Based on this experience, my conclusion is that the Agile-like context would benefit from detail requirements that contain the most complete content possible. Requirements in either Shall or User Story form can and should include acceptance criteria. This would support any level of testing required.

Buy A Custom-Built Solution

The model of custom-built solutions that I am most familiar with involves the following steps:

The business provides requirements for what is to be delivered and selects a supplier.
The supplier produces a Statement Of Work (SOW) based on the requirements, specifying what they agree to deliver.
The supplier delivers the solution for UAT and bug fixing.
The supplier expects ‘final’ payment and supports warranty period.

My most recent experience involving a supplier was from the business perspective. The development form that the supplier used was Agile. But given that they were relying on client-provided requirements rather than embedded SMEs, they were really only Agile-like. Nor was the detail in their SOW in user story format. The crucial point about this context is that it necessitates the requirements content, regardless of form, to be complete and detailed at the point in time the supplier commits to deliver for a contracted cost.

Buy A Package Solution

Package solutions are almost always a compromise between requiring customization to support the acquiring organization’s current business processes and adjusting the organization’s current business processes to align with what is supported by the package ‘out of the box.’ Any customization required most often is done by the package supplier. If customization is wanted, then requirements for that work falls into the Buy context described above. Even if functional customization is not necessary, there will likely be interfaces and/or reports that need to be developed or customized. Each of these will require detail requirements to support that development. Again it is the content of that detail that is critical, not its form.

So basically regardless of any build or buy context, detail requirements in one form or another are involved – ideally providing unambiguous content. So let’s have a look at what level of detail should be provided for different types of requirements.

Content Detail for Report Requirements

In the previous article the following example of a high-level report requirement was presented:

The system shall support on-line customers being provided with the details of the order that they just placed including a list of items purchased, the amount charged, and expected delivery date in an email so that they have an off-line record of their on-line purchase.

The objective of a Report HLR is to describe it just enough so it is understood in terms of its purpose and value to the overall business information system. During detail requirements, the trick is not to record the detail as a series of individual detail requirements. The detail should ideally be specified in a report template.

A proper report template provides for capturing required information such as frequency, delivery method, and selection criteria. There should be provision for including a layout of the report showing relative placement of headings and labels. Lastly, the template should cater for recording supporting information about the fields seen in the layout. Fields like “Customer Number,” “Transaction Date/Time,” and summary total fields would need little or no explanation. But fields that require special lookup or values derived from other fields should be described, preferably including examples.

With report details recorded in a template-based specification, the detail requirement itself actually can be very simple. The following are examples of how simple a report detail requirement can be when the detailed content is relegated to a specification:

User Story Format:

As a Customer, I want to receive an email containing the details of what I just ordered on-line so that I have an off-line record of my purchase.

Shall Statement Format:

The system shall produce an email to on-line customers upon their submission of each order.

Both requirements should include acceptance criteria:

Acceptance Criteria

Given an on-line customer
When the customer places an order
Then the Customer receives an email that conforms to the “Customer Order Confirmation Email” specification found Appendix C.

While acceptance criteria in the Given/When/Then format has its origins in Agile, there is no reason it can’t be included with Shall statements.

Assuming that all aspects of the report share the same priority, business rationale, and need to be tested together, there is little or no advantage in representing different aspects as separate detail requirements.

Content Detail For Data Requirements

When the scope of a project is known to include new types of data (records and/or fields), ideally it’s good for these to be included as detail data requirements. The previous article had this example data HLR:

The system shall support establishing new customers, including capturing details such as name, address, and contact information, ensuring that every customer is uniquely identifiable. E.g. Fred Smith assigned customer number 555123, The Carter Foundation assigned customer number 654287.

From a detail requirements perspective, new record types needed in the business information system should be named and defined. Volume-related estimates are good to have. For new fields (including links to other tables) again business name and definition are useful. For fields, the details of their data type and size should be specified.

Depending on the complexity of the information there may need to be some database design done on the way to a solution. Still, for any new tables and/or fields designers and database administrators need specific information that can only come from an SME. As with reports, the types of information needed about data is common and best served by a Data Definition template.

This again means that all that is needed is a single detail requirement in one form or another. The Shall format example would look like this:

The system shall provide storage for information about Customers as described in the Customer data specification found in Appendix D.

Again, while the above requirement does not appear detailed, the overall information provided (mostly in the template specification) provides what is needed to get the job done. Also like the detail report requirement, if the full content is not provided, when it comes time to design and/or build the data solution an SME will need to be consulted.

Content Detail For Interface Requirements

System interfaces either import data that’s needed by a business information system or else export available data needed by some other system. Where the project scope has identified that information needs to pass between systems, there should be a high-level requirement that represents that need. The example from the HLR article was:

The system shall support sourcing of foreign exchange rates from the European Central Bank on a daily basis to support currency conversion when the on-line customer deals in a different currency than the supplier of a product.

From a detail requirements perspective, an SME should know what data items are expected from or by the other system. It should be possible to list those data items based on the existing (or under development) business information system.

If the number of data items is small, they can be listed right in the detail requirement. If larger or complex data structures are involved, the details can be described separately (dare I say using an interface template?). An example in user story form with a self-contained list of interface data items would be:

As the system, I want to receive daily currency exchange rate data from the European Central Bank so that I can convert purchase amounts from a supplier currency to a customer’s preferred currency.

Acceptance Criteria

Given access to base exchange rates made available from European Central Bank
When the ECB exchange service makes new rates available
Then the following details about each currency is recorded and available for use converting between currency pairs:
- To Currency E.g. USD
- Effective Date
- Exchange Rate From Euro E.g. 0.89
- Rate Type E.g. Mid-Market

Data items in an interface list should include details such as attribute name, description, and examples. The objective is to support the subsequent ‘mapping’ of corresponding items on each side of the interface during the interface development phase, where field details of size and type can be addressed. This technical mapping is done by someone familiar with the business information system’s database schema. That person will also need access to the external system’s interface specification.

Upcoming Articles

This article included discussions of content for Report, Data and Interface requirements. The two requirement types that were not addressed were Functional and Non-Functional. Types of Non-Functional requirements are each very different and the detail content will not be covered in this series. But detail functional requirements are so important that the next two articles are devoted to them (including adding Use Cases to the mix of possible forms of representing detail). Stay tuned.

7 Habits of Highly Effective BA People

Written by Yaaqub (Yamo) Mohamed on June 28, 2016. Posted in Articles.

When I was 17, I stumbled upon the fascinating world of audiobooks. The first audiobook that I ever heard was the life changing “Seven Habits of Highly Effective People“, read by the author himself. The riveting real-life examples, practical advice, and the passion in delivery made this book have a huge impact in my life.

In this post I would like to summarize the seven habits, and provide a parallel of how business analysts can adapt them to be more effective with 2 key BA lessons per habit. These habits have a universal appeal, and could be observed as a common theme with highly effective people.

Let us see what BA lessons we can derive out of them.

1) Be Proactive

In Summary: I still remember the depth of meaning in this simple statement that I felt when Dr. Covey explained what it means to be proactive as human beings. Owning up to the responsibility for our own lives and the actions we take is the essence of this habit. When you dissect the word “responsibility”, it splits to mean “the ability” to choose a “response”. Being proactive means that you exercise this ability consciously without being reactive to changing stimuli and situations.

2 BA Lessons:

Be proactive with your career – decide where you want to go this year, and for the next few years in terms of career growth. Make growth happen, don’t expect it to happen on its own.
Be proactive with your work – for any business analysis work, planning, and monitoring are key aspects and often ignored. There should be a definite meaning in the BABOK having the “Business Analysis Planning and Monitoring” as the biggest knowledge area. Explore this area, learn more and implement it in your work.

The Flip Side: If you are not proactive, you will be reactive. A victim of the forces and circumstances surrounding you. Decide to act, and not be acted upon.

2) Begin with The End in Mind

In Summary: Mental visualization is extremely important. Covey says that all things are created twice: first, the mental conceptualization and visualization and a second physical, actual creation. Becoming your own creator means to plan and visualize what you’re going to do and what you’re setting out to accomplish and then go out and creating it. As a part of this habit, Covey adds: “The personal mission statement gives us a changeless core from which we can deal with external change.”

2 BA Lessons:

Set professional goals and milestones – if you are planning on a CBAP or PBA certification or completion of a course, set them as goals. Track your progress by marking milestones on a calendar.
Visualize success in your current project – conceive and believe that you will make your current project or endeavor successful. Visualize it.

The Flip Side: Lack of goals and milestones causes lesser focus and can lead to doing less than ordinary work.

3) Put First Things First

In Summary: With your power of independent will, you can create the ending you want to have. Part of that comes with effective time management, starting with matters of importance. Then tasks should be completed based on urgency after you deal with all the important matters. If you deal with crises, pressing problems and deadline-driven projects first, your life will be a lot easier. The essence of time management is to organize and execute around priorities.

2 BA Lessons:

Prioritize the sequence of analysis work – when analyzing needs of the stakeholders and assessing solution options, prioritize the resolution of core issues and needs first. One of my favorite mantras has been “an hour of effectively prioritized business analysis now, will save two hours of project management later.”
Read and apply “getting things done” – I would highly recommend you read “getting things done” by David Allen to start understanding the core principles of productivity.

The Flip Side: Not having priority causes you to do easy things first and may jeopardize the time that you would have available for more important things.

4) Think Win-Win

In Summary: If you believe in a better way to accomplish goals that is mutually beneficial to all sides, that is a win-win situation. “All parties feel good about the decision and feel committed to the action plan,” Covey wrote. “One person’s success is not achieved at the expense or exclusion of the success of others.” If you have integrity and maturity, there’s no reason win-win situations can’t happen all the time.

2 BA Lessons:

Always think of win-win for the business and the IT – ask yourself, how can you make a given situation a win/win for your team and the business? Even if doing a small thing can change the way business or your team feels about a decision or an outcome, you have achieved win/win.
Build effective relationships with your stakeholders – to understand win-win properly it is imperative that you know the real expectations and attitudes of various stakeholders.

The Flip Side: You will fall into a win-lose, lose-win, or a lose-lose situation, which is not the best outcome.

5) Seek First to Understand, Then To Be Understood

In Summary: If you’re a good listener and you take the time to understand a concept, it will help you convey your opinions, plans and goals to others. It starts with communication and strong listening skills, followed by diagnosing the situation and then communicating your solution to others.

2 BA Lessons:

Practice listening skills – leave some silence when needed. Listen with an intent to paraphrase, act like a news reporter where every detail from the person you are listening to, matter.
Diagnose before you prescribe – do the ground work for any situation that you encounter. Explore the various facets of a fact or truth and then arrive at a conclusion. Sometimes it’s best to park your ego.

The Flip Side: Missing out on the true intentions and ideas from others (by not giving them a chance to be understood first), can cause apprehension within the team.

6) Synergize

In Summary: Synergistic communication, according to Covey, is “opening your mind and heart to new possibilities, new alternatives, new options” This applies to the classroom, the business world and wherever you could apply openness and communication. It’s all about building cooperation and trust.

2 BA Lessons:

Focus on building strong relationships with your team and stakeholders. Build trust, deliver what you promise – build cycles of promising and delivering on your promise.
Buy lunch or coffee for a team member or a key stakeholder – if you haven’t done that yet; do it.

The Flip Side: You cannot succeed as a business analyst without adequate cooperation and trust.

7) Sharpen The Saw

In Summary: Sometimes you’re working so hard on the other six habits that you forget about re-energizing and renewing yourself to sharpen yourself for the tasks in front of you. Some sharpening techniques include exercise and nutrition, reading, planning and writing, service and empathy and commitment, study and meditation.

2 BA Lessons:

Sharpen your hard skills – learn more about a technique that you already know by applying it to a different fictional scenario or problem.
Sharpen your soft skills – join a Toastmasters club, read books and attend workshops that will help you become a better writer, speaker, and listener. Listen to the podcasts, read blogs, etc. to learn real tips on how to improve your hard and soft skills.

The Flip Side: If you don’t sharpen your skills and keep yourself rejuvenated you won’t be in an optimal state of performance.

Have you read “The Seven Habits of Highly Effective People?”

Which is your favourite habit? Do you have any additional BA lessons to add?

Please use the comment space below to add your comments and thoughts.