Tag: Business Analysis

Survival Guide: Bouncing Back and Forth Between Agile AND Waterfall

Written by Angela Wick on June 8, 2017. Posted in Articles.

Are you bouncing back and forth between agile and waterfall? It’s quite common these days for Business Analysts to grapple with both agile and traditional approaches to requirements and development work.

This can be frustrating, and Business Analysts may feel like a ping pong ball, getting smacked back and forth between two different worlds.

Assuming this scenario is not going to change, Business Analysts need to find a way to reduce their frustration level and think about their work a little differently. It’s time to change up the game!

Have you ever heard a coach tell an athlete, “Be the ball.” I never understood this advice, but it doesn’t work for Business Analysts in our Agile/Waterfall ping-pong scenario. So, let’s change perspectives. Instead of getting smacked around by multiple methodologies, Business Analysts can take charge of their methodologies. It just takes a shift in thinking, like this:

Now the Business Analysts are in the power position, taking charge of how to approach each incoming ping pong ball. Some might require finesse, some might require backspin, some might require a long volley, and we might even duck and let some fly right past us.

It’s the same for Business Analysts moving between agile and traditional projects—they modify their approach to match the work that is flying at them. The best way to survive and do consistently excellent requirements work is to consider what stays the same and what’s different.

To explore the similarities and differences, let’s see what happens when an agile ping pong ball and a waterfall ping pong ball collide. Hello, ping pong Venn diagram!

Let’s start with what’s different—team structures and team operations/procedures. In most cases, the structure of a traditional team looks a lot different than an agile team. A traditional team might have a defined hierarchy, where an agile structure might be flat, with several self-organized teams with loosely defined roles. The way the teams operate could be quite different too including the way the team collaborates, the timing and sequence of tasks, the process for reporting and measuring progress, etc.
BAs need to learn to roll with these differences, but luckily these differences don’t impact core Business Analysis work. It turns out the things that remain the same, in the center of our ping pong Venn, are the most important components of good requirements regardless of methodology. If Business Analysts focus their energy on these three areas, it will reduce the frustration of bouncing between Agile and traditional approaches.

Focus on the Customer

Both approaches demand we look at requirements from a customer point of view. The customer point of view carries most requirements and rarely fails us as a place to start requirements conversations. In both agile and traditional approaches, BAs are called to expand the definition of customer to include everyone who uses the solution internally and externally. BAs are also called to find innovative ways to identify and meet each customer’s rapidly changing needs.

Cultivate Conversations

Successful BAs in both agile and traditional environments use powerful conversations as the focus of their requirements process. Even in traditional/waterfall approaches, conversations are critical to getting to well-written requirements.

Powerful conversations take place with individuals or in groups and require a variety of elicitation techniques including brainstorming, games, models and visuals. Powerful conversations should be layered with whitespace—this means giving stakeholders time to process their thoughts internally before large group discussions.

Whether you are using an agile or traditional approach, cultivating conversations means dialog comes before requirements documentation. BAs let go of the temptation to hold a meeting to “review” a document or items in a tool before the team has a powerful and meaningful dialog. BAs who focus on conversations know that dialog before documentation speeds up the requirements process for both agile and traditional projects.

Avoid the HOW

Digging into the technical details, before the team understands customer needs, damages agile and traditional projects. So, let go of technical details. The BA role helps the technical team understand the needs and even collaborates on possible designs to meet the needs, but BAs should avoid the urge to tell the technical team exactly how to develop the solution.

Many BAs have knowledge of the technical details but realize this knowledge becomes outdated quickly. It can be tough to let go of knowledge, but remember, technical knowledge is not what makes BAs successful. Instead, focus on the user, goals, data, rules, and business process all with an eye on the future state. Don’t let your knowledge of the current or past keep you stuck there.

The truth is that BAs need to be versatile to survive! They need to be able to handle a wide variety of ping pong balls. This is not a new expectation. Successful BAs have always been able to operate in diverse environments. No teams or organizations work the same. Global teams, virtual teams, agile teams, hybrid teams, vendor teams and even internal teams choose different approaches to project work. Successful BAs stay focused on customers and conversations regardless of the methodology their team uses to deliver solutions.

Please leave your comments below.

Can the Business Analyst Survive the Future?

Written by Yvonne Harrison on June 7, 2017. Posted in Articles.

In the early 1800s, lacemaking was a necessary source of income for women and families with the lace fetching a reasonable price when sold.

By 1843, with the advent of lacemaking machines, prices collapsed, and factories employed women and children for a pittance. Most wages were barely enough to live on, and many families were thrown into subsistence living. (Ivy Pinchbeck, 1977.)

The Eastman Kodak Company dominated the sales of camera film, employing thousands of people through much of the twentieth century—until digital technology arrived in the 1990s and unable to adapt fast enough or target the right products, Kodak filed for Chapter 11 in 2012.

Automotive parts manufacturing workers are now in the same situation. What was once a job that allowed men and women to support their families, barely pays a living wage and has a high degree of injury associated with it. (Waldman, 2017.)

And on a personal note, my great-great-grandfather earned his living as a wheelwright. That’s a person who builds and repairs wooden wheels and is a profession that had been around for centuries until the arrival of the modern automobile. In a few short decades, the craft of the wheelwright had nearly disappeared.

It seems that about forty years (or less) is all it takes to destroy a formerly secure job. The question is, could it happen to the role of the business analyst, and when?

This isn’t a strange question when even coders are experiencing a shift in how their role is perceived.

In February of 2017, WIRED magazine published an article asking if coding was the next blue-collar job in America. The article pointed out that coding had become a two-tiered career choice. Silicon Valley only employs eight percent of the USA’s coders and programmers. The rest are in other business sectors. “These sorts of coders won’t have the deep knowledge to craft wild new algorithms for flash trading or neural networks. Why would they need to? That level of expertise is rarely necessary at a job. But any blue-collar coder will be plenty qualified to sling Java-Script for their local bank.” (Thompson, 2017.)

In an interview with NPR, Clive Thompson, the article’s author, noted that a huge number of available coding jobs don’t require the high-level skills that would get a person a gig at Google. “But the truth is, you know, an awful lot of programming doesn’t require or need that type of, you know, crazy pouring out of creativity. I guess it is more like maintenance or the slow stable making sure that a company is sort of moving along, that its software is working.” More importantly, this sort of coding doesn’t always require a college degree. There are plenty of self-taught coders that are gainfully employed, and there are more and more courses available where a person can get a junior level position after completing the syllabus.

If you look up the definition of blue-collar via Wikipedia, the page says that a blue-collar worker is a person who performs non-agricultural manual labor that can be skilled or unskilled. Examples of blue-collar jobs include firefighting, manufacturing, and mining. But why would Clive Thompson compare what’s an obviously non-physical profession to a blue-collar job? I think if it’s viewed in terms of the changes happening now, more and more blue-collar jobs will shift (and have shifted) from the purely physical. Many blue-collar jobs are already there. Working on a car assembly plant in the 21st century means working with, and alongside, technology. Modern mining operations require a similar level of understanding about the machinery once the person in the entry-level position wants a promotion. However, the primary identifying characteristic of the jobs will continue to be the requirement to produce the same things over-and-over-again. Viewed from that perspective, assembling code in the future could wind up like assembling a car. Everyone tackles a piece of code that they repeatedly produce (without much variation), but they never do more than that.

This brings me back to the role of the business analyst. Viewed from the blue-collar perspective, the role of business analyst shares much of the same characteristics as ‘every day’ coding. It’s rare that we work on a project that’s inventing something new, and it’s also rare that we need a vast amount of creativity to get the job done. We perform a lot of the same actions on every project, with minimal variation on the theme. Even the BABOK states that the job can be done by many different roles. “A business analyst is any person who performs business analysis tasks described in the BABOK® Guide, no matter their job title or organizational role. (…) Other common job titles for people who perform business analysis include business architect, business systems analyst, data analyst, enterprise analyst, management consultant, process analyst, product manager, product owner, requirements engineer, and systems analyst.” (BABOK v3.)

There are many people performing business analysis, under many guises, and more joining the field every day as the demand increases. We come from a variety of backgrounds (like coders) and don’t need a specialized college degree. Much like the coders Clive Thompson talks about in his article, we’re the workers, “making sure that a company is sort of moving along.”

And this creates an issue because this means that there are many factors that could disrupt the role of the business analyst in the future.

The most obvious one is supply and demand. To date, there’s always been a demand for business analysts. The market is currently in an equilibrium where supply and demand appear evenly matched, and the price the market is prepared to pay for business analysis skills means most people in the role can maintain a solidly middle-class existence.

However, the law of supply and demand also says that if ever the time arrives where the demand side decreases because the economy is forcing organizations and businesses to cut back on spending, or an oversupply of business analysts means the price can be lowered for the service, then the role becomes far less attractive.

The role can also be disrupted by technology and methodologies. Agile already attempted to do this with a focus on developers and the business working directly with each other. With AI on the horizon, it’s entirely possible someone will figure out a way for a customer to answer a series of questions and the AI will synthesize the answers and produce a decent specification or set of user stories as an output.

The only thing that may save the business analyst’s role in the near future is that the role also falls into the pink-collar job classification. Originally used to denote a group of service jobs predominantly performed by women in the 1970s, the term has slowly morphed into a way to classify jobs that require social skills and consists of interacting with people and customers.

“For an office worker, that could mean being able to communicate across departments. For someone in customer service, it’s interacting with another complicated human. For a care provider, it’s the empathy to help someone vulnerable and in need. These are all skills robots are really bad at—at least for now. And they have, over the last three decades, become increasingly vital in the labor market.” (Greenfield, 2016.)

But as we all know, industries change quickly and roles and jobs that were seen as necessary, suddenly become unnecessary.

So, for now, and in the near future, our jobs as business analysts might be safe. Our social skills and certifications may save us. But as plenty of people have found out the hard way over the centuries and decades, disruption in an industry comes swiftly, and the effects are devastatingly immediate.

Bibliography
Clive Thompson, “The Next Big Blue-Collar Job is Coding”, WIRED (2017): https://www.wired.com/2017/02/programming-is-the-new-blue-collar-job/.
IIBA, BABOK v3 A Guide to the Business Analysis Body of Knowledge: (International Institute of Business Analysis, Toronto, Ontario, Canada, 2015).
“‘Wired’ Declares Coding As Next Blue-Collar Job Boom,” NPR (2017): http://www.npr.org/2017/02/10/514566974/wired-declares-coding-as-next-blue-collar-job-boom.
Rebecca Greenfield, “Forget Robots—People Skills Are the Future of American Jobs. You might call it pink-collar work. Experts call it the future of the labor market”, Bloomberg (2016): https://www.bloomberg.com/news/articles/2016-12-07/forget-robots-jobs-requiring-people-skills-are-the-future-of-american-labor.
Peter Waldman, “Inside Alabama’s Auto Jobs Boom: Cheap Wages, Little Training, Crushed Limbs. The South’s manufacturing renaissance comes with a heavy price”, Bloomberg (2017): https://www.bloomberg.com/news/features/2017-03-23/inside-alabama-s-auto-jobs-boom-cheap-wages-little-training-crushed-limbs.
Ivy Pinchbeck, Woman Workers in the Industrial Revolution: (Frank Cass and Company, 1930, 1969,1977).

You Desire Success? Learn to Manage Daily to Your Top 3 Priorities

Written by Neal Whitten,PMP on June 6, 2017. Posted in Articles. 2 Comments on You Desire Success? Learn to Manage Daily to Your Top 3 Priorities

Managing daily to your top three priorities is crucial to your professional success. However, my experience is that most people in our craft do not manage their to-do list effectively.

This article will show you how. Doing so can boost your effectiveness, reputation, and career.

Instantly Identify Your Top Three Priorities

If I were to put you on the spot and ask you what are your top three priorities or problems at work right now—by the way, priorities and problems mean the same thing to me in this context—and you could not rattle them off within three snaps of the fingers then you are not a consistently effective leader. You might be thinking how dare I judge you by so little information; that if I would give you a few minutes, then you could come up with your top three priorities. But if you need time to identify them then I restate my assertion that you are not a consistently effective leader. Instead, you are managing your day by the plethora of interruptions that come your way; by the noise and the minutia that fall over you. You are allowing your day to be managed by others instead of you taking charge and managing to the most important priorities. You are too soft if you are not seizing control of your domain of responsibility and primarily managing to your top three priorities each day.

To-Do List

Let’s talk about how to do this. Most of you likely start your day with a to-do list of work items. That’s good. You should. However, what I do—and perhaps some of you do as well—is create the list the night before. Why? Well, I already have had a busy full day, and I know where I want to hit the road running when I come into work the next day. Therefore, the night before is a great time to populate the list. But another reason I’ll create the list the night before is to focus on the top three items on the list—the top three priorities. Let’s say the list has ten items: the top three and a bottom seven. Now, most of you will likely have lists with more than ten items, but I want to make the math simple for illustrative purposes. When I go to sleep at the end of the day, my mind—my subconscious—is working on solving or moving towards the solving of one or more of these top three problems. When I wake the next day, these problems are either solved or well on their way to being solved; I have a better grasp of what I need to do moving forward. All of us have this ability to help resolve problems when we sleep. Regardless, if you, instead, choose to take 5-10 minutes of quiet time at the start of your work day to create your to-do list, that’s fine.

Focus Predominately on Top Three Priorities

Now, let’s say that you are traveling home at the end of your work day and you recognize that you have not made headway on any of your top three priorities, but you have managed to cross off all of your bottom seven: Do not feel good about your accomplishments that day! Why? Because you worked on the wrong things. If, instead, when you head for home, and you have not worked on any of your bottom seven but managed to make significant headway on just one of your top three, you should feel very good about your accomplishments for that day. And here’s why: Your efficiency to work on your top three priorities defines your value—your contribution—to your organization, it defines your career; not the bottom seven.

30 Minutes or More Available, Work on Top Three

You might be thinking: Neal, it sounds like you don’t care if I work on my bottom seven. You’re right. I don’t care. In the big picture, they are insignificant. Look, if you have five minutes between meetings and you can eliminate one of your bottom seven, then go for it. But if you have 30 minutes or more between meetings, do not work on the bottom seven. 30 minutes is what I call significant time. You should be working on your top three priorities—they define your career.

Work Off Top Priorities within 2-3 Days

Your top three priorities on the list should be worked off the list typically within 2-3 days. If occasionally you have a top-three item on the list for up to a week that’s okay. What’s that? You say that the items that make up your top three typically would take weeks or months to solve and you would not know how to remove them from your list in just 2-3 days. Okay. I’ll show you how. Let’s say one of your top three priorities will take you six weeks to solve. Then put a six-week plan together. Identify the activities, their dependencies, their durations and who owns them. Then get agreement from all the people necessary to make the plan whole and fully committed and track the six-week plan like you do any other plan. Now replace that priority item from your to-do list with a new one.

What’s that? You say the six-week plan hasn’t completed and, therefore, the problem is still open? That you think the problem should remain on your list until it is solved? Look… You now have a good working plan to get it resolved. It’s being taken care of. You will track its implementation with the frequency you feel it justifies. Remove the item from your top-three list and replace it with another very important item that now needs timely attention.

Occasionally, Not Working Top Three Is Okay

What if you come to work occasionally and find you are not able to work on any of your top three priorities because of that day’s firefights and “please handles”? If this happens only occasionally, that’s okay. You work in a complex, dynamic environment. However, if it happens routinely, it’s not okay. If you cannot routinely work off your top three priorities, then you are the problem. If you are not working them off, no one else will—this is your domain of responsibility. You need help. You might be overloaded with work and need some relief; you might be poor at managing time, or it could be something else. Whatever. You need to seek and obtain the appropriate help.

Number One Reason Why Projects Fail

This is a good time to share with you what I believe may be a profound assertion. We have all seen lists touting the top 10 reasons why projects fail. The usual suspects include weak requirements, scope creep, lack of user involvement, unreliable estimates, incomplete staffing, poor communications, weak senior stakeholder support and others. However, from my experience, these lists miss the biggest reason—the number one reason—why projects fail: Because the project manager does not manage to his or her top three priorities on a daily basis. This is so important that I’m going to repeat it. The number one reason why projects fail is that the project manager does not manage to his or her top three priorities on a daily basis.

You might be wondering how come I’m so smart to get this while it appears that others haven’t? Well, I’m not that smart, but I am an old guy who has been around a long time. Longevity and persistence helps me pick up things. For example, over the years I have performed reviews on hundreds of projects in trouble. When I do, I always conclude with identifying the top three problems—the top three priorities—that the project manager needs to address immediately. When I examine these top three lists, the ah-ha moment presents itself. The top items on the lists almost always should have been resolved not days earlier but weeks or months earlier—sometimes years depending on the duration of the project. The lists show that the project managers were not effectively focusing on their top three priorities on a daily basis; otherwise, these problems would have been resolved or under control. So, again, the number one reason why projects fail is that the project manager does not manage to his or her top three priorities on a daily basis. This is a fundamental fact that knowing and adjusting your behavior to can significantly increase the success of your projects—and your career.

By the way, the article might have appeared to focus on Project Managers, not Business Analysts. Everything said here also applies to Business Analysts. The number one reason why Busines Analysts fail is that the Business Analyst does not manage to his or her top three priorities on a daily basis.

Now, become your imagined self!

How to Discover Useful Requirements for Business Intelligence

Written by Kent McDonald on May 31, 2017. Posted in Articles. 1 Comment on How to Discover Useful Requirements for Business Intelligence

“My users are asking for a report, but how do I make sure I truly understand their needs and properly convey that to the rest of the delivery team?”

Asking for a report is great, but it is a loaded word. People use the word “report” to mean many different things.

A report is a solution in search of a problem. You may know what your stakeholders want on the report, but until you identify why they want the report, you enable their solution seeking.

When you want to understand a stakeholder’s business intelligence needs completely, the following steps often prove very helpful:

Start with the questions stakeholders want to answer and decisions they want to make
Focus on value and feasibility to determine what to do next
Dive into detail only when you need to

Start with Questions and Decisions

When your stakeholders ask for a report, you want to know why they want that report, but you do not want to ask why. Why not?

Asking “why do you need a report?” is not going to provide you with the key insights and information you need and may make your stakeholders think you do not believe they have a need at all.

To avoid that uncomfortable situation, I have found that Socratic Questioning is a good route to go. The question I like to start off with is “What questions are you trying to answer or what decisions are you trying to make?”

When your stakeholders describe the questions/decisions, listen for phrases such as:

I want to know…
I want to decide…
I want to determine…

These help to identify the initial big chunks of value you can deliver in your business intelligence efforts.

Say you are working on a product to allow the audience at Olympic events to vote on the competition – say platform diving – and your stakeholders want to incorporate reporting into that product.

You talk with your stakeholders and find out that they want to know how votes can vary depending on characteristics of the audience or the competitors. That may result in the following things that you want to explore:

I want to know if audience members vote differently based on their gender
I want to know if audience members favor athletes from their country
I want to know if audience members evaluate athletic performances the same as judges
I want to know if audience member age impacts how they evaluate performances.

You can easily capture these in a user story, job story, or another template of your choice. The key is that you know what your stakeholders hope to accomplish with the reports, so you can guide the discussion to find out what your stakeholders hope to accomplish.

When you have those conversations, listen for nouns. They represent the pieces of information you need to know. Also listen for phrases such as “by gender” or by country They indicate how to organize the data, including what dimensions you may need.

In our examples above, the nouns you will most likely pick up on are audience members, athletes, and judges. The dimensions then may be audience member gender, audience country, athlete country, and audience member age.

Focus on Value and Feasibility

Once you have identified what you want to work on, you need to decide the order in which you work on it.

Start by prioritizing the questions and decisions your stakeholders are interested in based on value. Which of those questions and decisions are most vital to your stakeholders’ objectives? It may be the question/decision that provides your stakeholders the biggest lift or is most critical to address other questions and decisions.

Then, consider feasibility. Feasibility focuses on whether the data you need to address the questions and decisions is availability and organization of the available information. If the information is not readily available, consider alternative methods and their difficulty in obtaining that information.

Some pieces of data may present some substantial risks from the perspective of whether you will be able to get that data. If that data is critical to some of the more important questions/decisions, you may decide you need to tackle that data first.

Feasibility also drives the order in which your team delivers the data for a specific question/decision. As a result, you may provide overall prioritization of which questions/decisions to address in what order, and then leave it to your team to decide the order of the smaller bits of work necessary to deliver the ability to answer a given question or make a specific decision.

Dependencies play a part in considerations of feasibility. Often the answer to one question becomes an input to answer another question, so you have to consider those interdependencies when you decide the order of the questions you tackle.

Prioritization is most effective when it is a team discussion. Start with which questions you want to answer or decisions you want to make first, but then revise that order based on the feasibility involved in getting the data necessary for those questions or decisions.

Only Dive Into Detail When Needed

I noted above that you want to listen for nouns and pointers to possible dimensions. Noting what comes up during the normal course of conversation is ok, just avoid the temptation to dig too deep too soon.

You do not know which stories you are going to need to do, so you do not want to expend too much effort fully understanding stories you are not going to do. When do you dig into the details?

When you have initial conversations with your stakeholders to understand the information they seek, you may sketch out a very rudimentary report during the conversation to make sure you understand what they are asking for. Stop when you have enough information to determine what order you want to deliver those questions and decisions.

In some cases, you may need to dig a little bit if you identify a piece of data which may prove a somewhat difficult to obtain.

Wait to delve into all the details of the data (definitions, transformation rules, valid values, or other factors) until you are preparing information for a team to deliver the necessary data to answer a question or make a decision.

Business Intelligence Can Be Done Iteratively

It is possible to deliver data warehouses in an iterative, incremental fashion. The key to making that happen and work is to organize your increments around questions your stakeholders want to answer or decisions they want to make. Then consider value and feasibility to prioritize those questions/decisions, and avoid the temptation to dive too deep too soon.

What experiences do you have working on business intelligence projects? Leave your thoughts in the comments.

Spinach and Wisdom

Written by Bob Prentiss on May 23, 2017. Posted in Articles. 1 Comment on Spinach and Wisdom

Spinach was never my favorite vegetable growing up. That green soggy and slimy mess on my plate just wasn’t something I was interested in eating.

“You know there are starving children all over the world. You are not leaving that table until you finish eating your spinach.” Our response was “Get me their address. I will mail it to them.” That was not an argument that would win over Mom.

Years later while working as a Business Analyst working on negotiating outsourcing contracts, cleverness was raised to an art form. A quick off-the-cuff remark that was clever could disarm the most well thought out point. Cleverness is always concerned with triumphing over one’s opponent in an argument or discussion. Negotiations became more of a game and less about understanding each other. A person is considered sharp, skillful and witty throwing out quip. You can of course also be viewed as sarcastic and mean spirited.

Many negotiations concluded, and contracts won. The art form of negotiation used cleverness frequently and very little business analysis. It was all about getting our needs met and overcoming any opposition. By this focus on overcoming the other side, we lost sight on really understanding the points of views of others and just forcing your point of view forward to win. Business Analysis was throw out the window to be successful.

Winning did not produce the great results we had cleverly negotiated. Many of the outsourcing agreements feel part within two years due to significant issues with outsourcing vendors. One agreement fell apart after six months. We just couldn’t understand why all our contracts fell apart. We later learned that our approach to not understanding the business problem and the business model of outsourcing vendors was a key factor in having these contracts fall apart. We won the battle. We got what we wanted. The problem was we were too busy being clever.

Society values cleverness. Twitter runs on 128 characters or less of cleverness in discussions on complex topics. TV is full of the clever one-liners going back and forth. Being clever never helps us resolve issues but rather makes them worse. I can make the quip about sending spinach to starving children by getting their address to win a battle but lose the war on spinach by having to sit at the table until it is completely eaten. I valued cleverness more and tried to feed it to the dog. Australian sheepdogs do not like spinach, so I was stuck eating it myself.

Wisdom is not always so valued when compared to cleverness. Wisdom is walking in someone else’s shoes to see the world through their eyes to understand their point of view. Wisdom is not about winning points in an agreement or negotiation. Wisdom is the observation, empathy, and thoughtfulness to gain deeper meaning and understanding. Wisdom is relating yours and others experiences together for the current issue at hand. Wisdom is slow and takes time. Cleverness is fast and quick.

It is hard being wise in an environment where speed is of the essence. We want to go faster and faster. We want to be clever. In choosing whether to be clever or wise, I would choose wisdom. Wisdom opens your eyes to all the possibilities and gives a deeper understanding to move forward productively. Granted that may take more time for Business Analysis but it is time well spent to protect our future investment.

A colleague of mine in the construction industry once said to me, “To build a house in 3 days – you have to design and plan for three years.” At the time, I thought he was nuts. The truth of it was that he was perfectly correct. In building a new development, we really could get a house framed with doors and windows, painted walls, electrical, plumbing and flooring all completed in 3 days. A customer bought the house on Monday, and it was ready to move in on Thursday. Solid good quality homes built from the ground up in a fraction of the time. Those three years paid off big time. The construction company saved considerable amounts of money by being able to close on houses faster.

Looking back at those outsourcing contract negotiations, it is clear to me that wisdom was missing. We did not look deep, did not understand their situation or expectations, and we failed even while getting everything we wanted. Wisdom would have driven us to walk in their shoes and understand them more fully before attempting to construct those agreements.

In the case of spinach, it may have been wiser to gulp down the cooked spinach and ask for raw spinach next time.

May we have the good sense to know when to be clever and when to be wise.