Author: Kent McDonald

How to Learn New Techniques

Written by Kent McDonald on January 3, 2017. Posted in Articles.

Introduction: The fourth thing I wish I knew when I was starting out as a business analyst was how to learn new techniques in a way that I can be most effective.

With the vast amount of techniques out there, it’s possible to become a professional student and spend all your time learning about new techniques, becoming an expert in every one. That’s not necessarily what I’m suggesting here. Rather, I think it’s important to be aware of the variety of techniques available, when to use them and how to quickly get up to speed on them when you need to. Here’s how I go about doing just that.

Keep an Eye Out for New Techniques

There are 2 categories of new techniques for business analysts:

Techniques that are new to you, but are practiced by other members of your team.
New analysis techniques that make you more effective.

It’s easy to decide when to do the first type of techniques – usually someone on your team has hit a bottleneck and needs some help to keep things moving. If you have some time available, or the work you’re currently doing is not as time critical, you can be a good team member and help. Hopefully, learning that new technique will also help you be better at business analysis. That was the situation I was in when working on a data warehouse project as a project manager/business analyst and found myself reverse engineering COBOL code to elicit business rules, modeling data, and developing SQL stored procedures. I primarily did those activities because they needed to get done, but they had the added benefit of adding skills to my toolkit I use to this day.

Deciding when to pick up new analysis techniques can be a trickier. You need to balance seeking continuous improvement with not falling into the shiny object syndrome where you think a new technique you hear about is the answer to all of your problems. I know this happens because I’ve fallen into that trap more often than I care to admit. What I have found works best is to find some people I trust and respect and listen to what they are talking about. This works best when you follow people that you know are practitioners because when they share their stories you know they are sharing things they have done. I compiled a list of Product Ownership Blogs and Newsletters on my blog that I follow to find out about new techniques. That list is primarily product management and UX focused because those types of techniques are very helpful for business analysts.

When you come across a new technique make sure you understand what outcome the technique produces, and when it is most applicable. If you explicitly look for this information, you may avoid falling victim to the shiny object syndrome. The other thing I suggest you do is keep a perspective of Just-In-Time instead of Just-In-Case learning.

Just-In-Time learning means you find out what the technique is, know when it’s appropriate to use, and where to find out more information. Organizations like the IIBA (in the BABOK Techniques section) and the Agile Alliance (in the Agile Glossary) provide descriptions of techniques at a level appropriate to understand what techniques are and when they are useful.

Just-In-Case learning means you go on a binge of downloading resources, buying books, and attending classes about a technique even though you aren’t sure when or if you will use it. When you do this, one of two things happen. You learn all this great info about this new technique, then don’t find an opportunity to use it and promptly forget everything. The other alternative is you learn all you can about the new technique and then you walk around with a proverbial hammer in your hand and everything looks like a nail. You applying the technique to solve every problem you come across even when it’s not a good fit. Don’t do that.

Search for Resources About How to Do It

Once you find an appropriate use for a technique, it’s time to do a deep dive into that technique. If you’re learning a technique to help other team members, ask those team members what resources they suggest.

You can also do a targeted internet search where you ask about the technique in a specific context, such as: “Story mapping for health insurance business intelligence”. If you don’t find any useful resources with those specific searches, you can always broaden your search. Pick the results that describe actual experiences rather that the resources that only explain the theory of the technique.

Wikipedia is a good place to start with information about the technique, but use it primarily to find out who initially created it or has expanded the use of the technique then look up resources from those creators. The Agile Alliance Agile Glossary that I mentioned is also a good place to find links to other resources both on the Agile Alliance site and off that provide more information about some techniques.

Targeted questions on LinkedIn groups can also be helpful. Just be prepared to separate the people who have used the technique from those who have read just read about it. Pay attention to people whose answers are like “when we tried this out I found” or “I usually like to do this…” over those who respond with prescription such as: “the daily standup must always be 15 minutes or less and managers must not speak.” When you find some people with actual experience using the technique reach out to them and pick their brains. Your own experience is the best teacher; other’s experience is almost as good.

Establish a Safety Net

This step is most appropriate when you learn a technique new to you but familiar to others in the team. Find someone on the team who is an expert in that technique that you can either pair with when you are doing the technique or run things by before you finish them. Since you are probably doing a task to help someone who is too busy, you’ll have to find a way to get this support that makes the best use of the other person’s time.

When I was doing the SQL development for the Data Warehouse project, my safety net was Mike, a skilled SQL developer in our area. He had limited availability for the project, so I did the development work and testing in a test environment, and then went over it with him. It was important for me to find out not only where I had written bad code, but also why it was bad code. Finding that out helped me to understand more general principles around writing SQL code that I still remember to this day. The same idea applies for any technique you learn.

One approach that teams use to allow members of the team to learn techniques and to provide safety net is called Staff Liquidity. It’s the idea where each member of the team assesses their abilities for a variety of techniques then when the team is deciding who is going to work on what, the people who are less familiar with an activity volunteer for items dealing with that activity first. That leaves more experienced people free so that they are available to coach and mentor. The idea behind this is twofold. 1) the knowledge about key activities spreads throughout the team. 2) The more experienced members are available to jump in when an urgent issue comes up without having an undue impact on the work of the overall team.

Just Do It

You can read about a technique and talk to others about how they’ve done it, but you really learn by doing it. You’ll learn it even better if you make recoverable mistakes when trying the technique out. If there is a new technique that you think may be helpful, make sure it’s appropriate in your situation and try it out. Start with the expectation that you may make some mistakes and be prepared to learn from those mistakes and figure out how you may do it differently in the future.

Limit the amount of time you try a technique the first time. You don’t want to spend a lot of time doing something without any feedback. Try something in a limited fashion and then get feedback on how the technique went, consider that feedback and think about how it will impact what you do the next time.

When I was doing the SQL development, I would write a procedure or two, then I would run those procedures in test and check them with Mike to make sure I was heading down the right path. If I made a mistake at this point it was recoverable because I was in a test environment.

These days I get the opportunity to expand my website building skills when I make changes to the Agile Alliance website. I pick an isolated instance of the new technique I’m trying, do it, then have some other members of the team look at the page to get feedback.

If you are taking a course on the technique, make sure the course includes an opportunity to try out the technique, if not in your own context at least on an example that is somewhat related.

Teach it to someone else

If you’ve used the technique and found it worked for you, and you think you are going to continue to use it, the best way to increase your knowledge and understanding is to teach it to someone else. Richard Feynman, a Nobel Prize winning physicist known for his ability to explain complicated topics to people came up with the Feynman technique which is a great formula for learning anything:

Choose a concept
Teach it to a Toddler
Identify Gaps and Go Back to The Source Material
Review and Simplify

Use the Feynman technique to describe the technique you have learned and tried out to help other people learn it as well, at the same time making sure you really understand it.

How Do You Learn New Techniques?

Those are a few of the ways I go about learning techniques. I’d love to hear what you have found works. Leave your thoughts and experiences in the comments below.

Just Because You Can Satisfy a Need, Doesn’t Mean You Should

Written by Kent McDonald on October 17, 2016. Posted in Articles.

In my previous article, Projects Tend to be Described in Terms of Solutions…

I described how to discuss the problem statement to reach a shared understanding about the need you are trying to satisfy with a project.

The natural follow on to that discussion is to ask the hard question – “Is it worth it?” In other words, is that need worth satisfying at all, or is there a solution that will allow us to satisfy the need effectively.

While that seems like an easy question, it’s one that doesn’t get asked as often as it should and when it does it isn’t always answered honestly. I’ve found a couple of approaches to ask and answer that question in an effective manner.

Use Strategy as a Filter, Not a Bucket

Todd Little poses the question “is your strategy a bucket or a filter“? Let’s dive into that a little more to understand what he means.

Let’s take a financial services organization that publishes their six “priorities” on their website:

Putting customers first
Growing revenue
Managing expenses
Living our vision and values
Connecting with communities and stakeholders
Managing risk

If this organization treats their strategy as a bucket, their portfolio management approach asks someone championing a new project (i.e., the sponsor) to describe how that project supports one or more of those priorities in order to be considered “strategic” and improve the chances of it being approved. The priorities may even be listed on the project initiation document template, encouraging sponsors to craft a story to force fit the project under one or more priorities. At this point strategy does not aid in decision making because depending on how good sponsors are at crafting stories, all projects could be positioned as strategic and the people responsible for making decisions about a project are left with no discerning information.

If, however, the organization used strategy as a filter, the questions asked about a project’s relation to the priorities are different. Instead of asking “does project A fit into the strategy (fit the priorities), the organization asks whether project A fits the priorities better than project B or other options. The strategy is used as a way of determining which projects are a better fit and should move forward. The other projects aren’t necessarily bad ideas, they just aren’t as strategic and therefore should not be done now in preference to others.

I like to take things even further to use strategy as an explicit filter. In this example, the organization would reduce the number of priorities, down to only 1 – 3. Then these “priorities” could be turned into decision filters expressed in the form of a question: “will this help us do X?” Each project would then be assessed by those decision filters. Projects where the sponsor can answer “yes” to that question would continue. Projects where the sponsor can’t answer yes to all the decision filters are stopped or are changed in a way that they can pass through the filter.

Using strategy as a filter aids in decision-making and provides coherent focus, which is what strategy is intended for. You can use it to clearly state what you will not do, which Michael Porter called the essence of strategy.

Define Success In a Measurable Fashion

The second way to effectively discuss whether something “is worth it” is to understand what you mean when you ask that question. That means establishing clear objectives that you can use to measure success. You want to measure success in terms of the need satisfied (i.e. the outcome) instead of based on a specific solution (the output). This allows your organization first to determine if the need is worth satisfying at all, and if necessary, assess different solutions to determine which one is the most effective in satisfying the need. You may even find that even though the need is worth satisfying, the cost of delivering any of the solutions outweigh the benefit gained from satisfying the need.

To help reinforce the characteristics of good objectives, Tom Gilb in Competitive Engineering suggests a set of attributes which you can identify for each objective. Below are those attributes with an example from a website looking to increase the number of subscribers to its newsletter.

Attribute	Description	Example
Name	Unique name for the objective	Increase the number of subscribers per month within 6 months.
Units	What to measure (Gilb refers to this as scale)	The change in subscribers to the newsletter in a calendar month average
Method	How to measure (Gilb refers to this as meter)	Subtract the number of subscribers at the end of the previous month from the number of subscribers at the end of the current month. Average those changes over the months being measured.
Target	Success level you’re aiming to achieve	Average increase of 25 subscribers/month
Constraint	Failure level you’re aiming to avoid	Average increase of 10 subscribers/month
Baseline	Current performance level	Average increase of 10 subscribers/month

A benefit that comes out of setting these attributes is the discussion that occurs in order to decide what the target and constraint should be, as it allows the team to get a clearer understanding of what success looks like.

Understanding the need first and being able to describe it via objectives gives you the opportunity to ask the question “Is this need worth satisfying?” So in the example above, the team can ask:

Is it worth it to increase the number of subscribers we add per month?
Do we need to do things to just increase the number of new subscribers, or do we also need to worry about retention of existing subscribers?
What is too much to spend trying to accomplish this?
What are we forgoing by increasing the number of subscribers?

When setting objectives, be very careful about unintended consequences. The discussion above focuses on using objectives for the purpose of making decisions about projects and/or products and can drive behaviors in the teams working on those projects. This is especially the case if those objectives are also used for the purposes of performance reviews. The financial services company referenced above faces a significant scandal dealing with employees creating fake accounts in order to meet the sales objectives they were measured by. This is a dysfunctional use of objectives if there ever was one and something you need to watch out for.

So How do you go about doing this?

In the article that started this series, I acknowledged that the lack of clear decisions about what not to do reaches up to decision makers in the organization. I also suggested that business analysts can play a critical part in getting those decisions to happen. The practices I suggested above are great ways to get the conversation started about whether a project is worth it, both when it is starting and after it is already underway. It’s important to ask probing questions, and you want to make sure that you are probing in the right places, and in the right manner.

I have found it helpful to have conversations with the broader team to understand what decision filters the team should be using and what objectives you should use to measure success. Then, if you realize that the project you are considering does not seem to pass those filters, or to meet those objectives, have private conversations with the project sponsor about your concerns. It’s generally not a good idea to call them out in front of the whole team, especially if you want to maintain an ongoing working relationship with that sponsor. You may find you may need some help with someone that has a good relationship with the sponsor either by coaching you through the discussion ahead of time or joining you in the conversation. You need to ask those questions; just consider how you go about asking them.

Have you had the opportunity to question whether a need was worth satisfying? I’d love to hear about your experience in the comments.

Projects Tend to be Described in Terms of Solutions

Written by Kent McDonald on October 4, 2016. Posted in Articles. 1 Comment on Projects Tend to be Described in Terms of Solutions

In my last article 5 Things I Wish I’d Known When I Started As A Business Analyst I said I wished that I knew that projects are often described in terms of solutions.

I actually realized this fairly quickly, but it didn’t occur to me to do something about it until a couple of years into my business analyst career.

I thought I was set when I started on a new project and was given a solution that just needed the specifics filled in. It was only after working on a few projects that I began to realize things were not as clear cut as they sometimes seem. I didn’t realize that people have a tendency to hang on to the first solution they think of when they face a problem and fail to question whether that first solution is the best one. As a result, when sponsors are asked to describe a project they inevitably describe that first solution they came up with.

One of your primary responsibilities as a business analyst is to dig into that solution and discover the underlying need. I’ve found a simple approach to accomplish this is to guide a conversation with the sponsor of the project and the team working on it around a problem statement.

Explicitly Discuss the Problem

I was working with a team in the middle of a commission system revision project. There were 11 people involved, including the sponsor, a couple of subject matter experts, and the majority of the delivery team. I wanted to get a better understanding of what the project was all about, and I wanted to find out if the team had a shared understanding of why they were doing the project.

I asked everyone to grab four index cards and a marker.

On the first card, I asked each person to finish this phrase: The problem of… [Describe the problem]

On the second card, I asked each person to finish this phrase: affects… [Who are the stakeholders affected by the problem]

On the third card, I asked each person to finish this phrase: the impact of which is… [What is the impact of the problem]

On the fourth card, I asked each person to finish this phrase: A successful solution would… [List the key characteristics that the solution, however implemented must have to be successful]

One set of cards looked like this:

The problem of: completing the monthly commission process in a timely manner affects: agents, commissions staff

The impact of which is: there is a delay for agents to get paid, commissions staff are constantly harassed by agents right at the time when they are the busiest (running the commissions process)

A successful solution would: speed up the commission process, decrease the number of times agents bother commissions staff

The team member actually states a problem, but then identifies multiple stakeholders who are affected, multiple impacts, and multiple characteristics of a good solution. That’s ok because you are primarily trying to generate information at this point.

Once everyone wrote their cards, I asked each team member to read their statement in order and place their cards on four parts of a table, each part corresponding to a section of the problem statement. If you are using sticky notes, you can have people put the sticky notes on four separate sheets of paper hanging on a wall.

When I had the group build their individual problem statements we ended up with 11 different perceptions of what the project was about, ranging from making some changes to the commission system to make it easier to maintain, to completely overhauling how the organization paid its agents. Needless to say, the team was a bit surprised about the differences in perspectives considering that the project had been underway for a few months. Everyone just assumed that they were “all on the same page” regarding what the project was all about until they did this exercise.

We had already gained value from the exercise because it exposed the disconnect between the group on the real need the project was trying to satisfy. We still needed to take the disparate items and condense them together into a single, consistent, agreed upon statement. I had the group start at the “The problem of” set of cards and agree upon a specific problem. Once the team came to an agreement on the problem, and only then, I had them move to the next the set of cards and repeat the process.

The end result was a consistent statement they all agreed to and could use as a guide to refer to when they were trying to remember, or fill someone else in on, what the project was all about. I didn’t keep track of what the actual statement was – the most important outcome of the exercise was the shared understanding between the team members.

That said, the output from the exercise was useful. The stakeholders identified in the “affects” group provided a hint at whose needs you want to satisfy. The “Impact of” identifies specific things you can look to eliminate, and the “characteristics of a successful solution” hint at potential acceptance criteria.

By working through each of the different portions of the problem statement, we were able to converge to a shared understanding of the purpose of the project. Later, the team members were able to use this as one way of deciding what they should and shouldn’t focus on.

Things to Consider

I did this exercise after the team had already started the project because that’s when I started working with them. Ideally, you’d like to have this conversation when the team is finding out about a new project. I’ve started a project with this conversation several times and found the teams are much better aligned with what they are trying to accomplish from the beginning.

The discussions that occur when formulating a consistent problem statement can also help the team focus. When your team crafts individual problem statements and then looks at all the pieces together, you identify several different problems, stakeholders, impacts, and characteristics of a successful solution. The discussions that occur in the effort to go from many problem statements to one raises issues, risks, and assumptions that everyone on the team may not have been aware of. Talking through those issues, risks, and assumptions helps your team build a shared understanding of the problem to solve and things to consider when picking the appropriate solution.

That’s just one approach I’ve used to extract a problem from a solution. I’m curious to hear what techniques you’ve found useful when you are in the same situation. Please share them in the comments.

Your Job Is Not to Elicit and Document Requirements

Written by Kent McDonald on September 14, 2016. Posted in Articles. 1 Comment on Your Job Is Not to Elicit and Document Requirements

In my last article, 5 Things I Wish I’d Known When I started As A Business Analyst I said I wish I knew is that my job was not to elicit and document requirements when I first started out.

Why did I say that? It comes down to the difference between outcome and output.

What is the Difference between Outcome and Output?

Before I go much further, I should probably explain what I mean when I use the words outcome and output in a context relevant to business analysts:

Outcome is the change in the organization and changes in the behavior of stakeholders as a result of a project.

Output is anything that your team delivers as part of your project. This could include requirements, documentation, processes, software, tests and other things that tend to be measured in order to gauge how the project is going.

The goal of every well-defined project is not to produce output; it’s to reach a specific outcome. A successful project seeks to maximize outcome with minimal output. Why do you want to do that? Well, you want to get as close to desired change in your organization and your stakeholders’ behavior with the least amount of initial and ongoing work as possible.

Requirements are (not the final) Output

To look at it another way, satisfying the needs of your stakeholders is the outcome you seek, and the solution you deliver to satisfy those needs is the output you use to reach your desired outcome. Requirements are outputs in that process, but they aren’t the final output that drives the desired outcome. They tend to be an interim output on the way to getting to the solution.

When you view the purpose of analysis as eliciting and documenting requirements you most likely have a couple of assumptions: 1) the best way to reduce uncertainty about the solution is to write everything down at the beginning of the project and 2) it’s possible to know what those things are. Those two assumptions generally end up false, so I’d rather work according to this assumption: we’re better off creating a shared understanding of the problem we’re trying to solve first, and let the specifics of the solution emerge as we get things underway and learn more about the problem space.

Changing those assumptions means looking at analysis as problem-solving and building shared understanding. Along with that comes a substantial change in how your team views requirements and designs. They are no longer deliverables that get tossed over the wall to the people performing the next step in the process. Now both requirements and designs are tools that teams can use to build a shared understanding of the solution they seek to deliver in order to reach the desired outcome.

How do you focus more on Outcome than Output?

Here’s a recent experience that shows how to maximize outcome while minimizing output.

For a little over a year, I’ve been the product owner for the initiative to revise the Agile Alliance website, membership and conference registration systems. When it came time to do a deep dive into the membership aspects of the system, I took it upon myself to write up all the specifics about membership – what information we wanted to track about members, what rules were relevant, and what types of memberships we had. It was a fairly short, yet comprehensive set of requirements. I was admittedly quite happy with them.

I was happy with them until the delivery team started developing functionality and they didn’t seem to pay much attention to the requirements. At first, I was perplexed, did I not clearly tell the team where the requirements were? Then I was irritated. Why weren’t they paying any attention to them?

Then it occurred to me that what I had done wrong was that I had focused on the requirements as an output, without considering how it contributed to our desired outcome, to increase membership. I didn’t talk with the delivery team to find out what was the best way to share information with them along the way as they built the various aspects of the membership functionality. We didn’t have conversations as we went along to specifically point out the relevant rules and pieces of information for the specific backlog item that they were working on at the time.

Once I came to that realization, we changed how we communicated. We still used the rules and data element information, but we used them more as reference points in the frequent conversations we had. We also started using examples on a more regular basis to talk through the specifics of a given backlog item. We found that me simply writing those examples down was not sufficient. In many cases the real advantage was through talking through them as the delivery team was getting started on a backlog item.

Lessons Learned

I should have known better to start the way we did. I realized it is easy to forget good practices when you’re in the midst of a project and the pressure is on. Here are some of those good practices I hope you don’t forget when you run into the same situation:

Take time to talk with your team about how you want to work, and the best way to communicate information in order to build and maintain a shared understanding. When you have those discussions, don’t be afraid to suggest approaches that your team is not familiar with if they are applicable for your project.
Document requirements collaboratively during your discussions with the team to build and maintain a shared understanding.
Stop thinking of analysis in terms of gathering and capturing requirements and instead think of it as solving problems and building a shared understanding.

I hope this story gives you some ideas on to focus on outcome over output. I’d love to hear some of your stories on how you’ve focused more on the outcome while minimizing your output.

5 Things I Wish I’d Known When I Started as A Business Analyst

Written by Kent McDonald on September 1, 2016. Posted in Articles.

I found myself in a reflective mood this weekend – driving from Iowa to Arkansas and back again to deliver a horse tends to do that.

One of the things I reflected on was the lessons I learned in my career and how knowing them would have been helpful when I started as a business analyst. Here are five things that I would tell my 1998 self, assuming I would listen.

Your Job Is Not to Elicit and Document Requirements

Yes, business analysts elicit and document requirements, but those activities are a means to an end. Analysis is about understanding your stakeholders and their needs, identifying the best solution for satisfying those needs in your particular context, and then building a shared understanding of that solution. Requirements play a part in that work, especially around describing the need, but they are certainly not the end product.

When the teams I worked with thought that the BA’s sole responsibility was requirements, my role was diminished and I lost the ability to make sure the project was delivering the right thing. On the contrary, when I stepped up and sought to understand why the project existed in the first place and then made sure everyone on the team had the same understanding of why, the project tended to go better, I enjoyed my work a lot more, and found I had much more influence on that project and in the organization.

Projects Tend to be Described in Terms of Solutions

The common advice repeated so much it’s almost become a cliché is that you must understand the need you are trying to satisfy first, then identify the solution that best satisfies that need. Yet, most projects are still initially described in terms of a solution, such as “Redesign the cover sheet for the TPS Report.” Why? Because it’s easier for people who are facing a problem to voice how they will solve it rather than to reflect a bit and describe the problem they are trying to solve. (This is where I resist the temptation to reference an overused Henry Ford quote about faster horses).

If you want to be effective at business analysis, learn how to drive to the real need in a way that makes your stakeholders eternally grateful that you came along. Your stakeholders are certainly experts in some things, but they may lack expertise in the capabilities of technology. They fall back on solutions they have seen in other contexts that may not apply to their current need. Bringing in other perspectives (i.e. the delivery team) can provide several other options for addressing the need in more effective ways.

Just Because You Can Satisfy a Need, Doesn’t Mean you Should

Sometimes when you uncover the real need, you realize that it could be satisfied, but that it doesn’t make sense to do so. Either the viable solutions cost more to implement than would be realized from satisfying the need, or the need is not that wide spread and your team’s time is better spent on other things.

A dysfunction I have seen is that organizations do not know how to determine constructively what they will – and more importantly will not – work on. This is apparent in the organization’s project portfolio which contains more things than the organization has the capacity to do within the identified timeframe.

This is a problem that stretches all the way up to the decision makers in the organization, but business analysts have a part to play in this. Although you as a business analyst may not make decisions about what projects get done or not, you certainly can influence those decisions, and even make sure they happen, by asking probing questions and driving to understand the real reason for projects. It’s not easy, but it’s better to raise the questions and drive some influence rather than keeping silent and not having any impact.

Learn as Many Techniques As You Can

There are several different techniques that are helpful for business analysts and BA Times is chock full of articles about how to do them better. With so many techniques available, it’s very helpful to be aware of as many techniques as possible and to really understand why you use them and when they are most helpful. There are enough great resources out there that you can pick that up when you need to actually use the technique. I’d much rather have a broad understanding of a wide range of techniques and when they are applicable then to be an expert in a few techniques. I find I’m much more flexible in my response to different situations and more useful on the projects on which I work.

People Don’t Want You On the Team Just Because You Are A BA

Throughout my career, I’ve had the opportunity to work in several different organizations on many different projects. When I started at a new organization, I was on a project because that project needed a business analyst. After that, I worked on future projects because of what I did and how I did it which included, but was not limited to, business analysis. Those experiences led me to the conclusion that while all projects need business analysis, not every project needs a business analyst.

I don’t think that rules requiring every project to have a business analyst help. Projects require a different amount of analysis. Let the business analysts work on those complicated projects that require a little of analysis, and coach people on the projects that are more straight forward.

Conclusion

There’s a lot more baked into these lessons that I didn’t have room to share here. In my subsequent posts, I’ll dive into more detail into each of these lessons and share a bit more about how you can apply each of these lessons learned. I’d also be interested in hearing what lessons you have learned, and if your experiences have been different than what I’ve described above.