How I Became a Salesforce Certified Administrator

How I Became a Salesforce Certified Administrator

This is my 3rd article on “How I became a …” So, I’m at it again, learning to do new things and going in directions I had not considered just months ago.

In February, I found myself sitting at a computer taking an exam for Salesforce Certified Administrator. Of course I’m familiar with this kind of setting, as I’ve already completed CBAP and AAC from IIBA, as well as PSM-1 from Scrum. I believe in the current economy, if you are in IT, certifications are a necessary part of ensuring you remain relevant.

But why go for Salesforce?

As I’ve mentioned before, I am a lifelong learner. That thirst for new skills, sources of information about the world and how it operates (or doesn’t operate, which is equally as important at times), is something that has driven me.

However, I needed to do something that would expand my usefulness into areas inaccessible to my previous experience. It’s not that I’m giving up Business Analysis, but that I needed to refocus it. And what I see from Salesforce will allow me to do just that.

Yet, these don’t really answer the question. How did I land on a decision to pursue a Salesforce Certification?

The short version is I got advice from some total strangers.

Well, they don’t feel like strangers to me because I’ve been listening to their podcast for over a year (3 years worth in 1 year). The ChooseFI podcast features two regular guys discussing Financial Independence, which I discovered can be highly relevant to Salesforce. In December 2019, I finally caught up with their backlog. And one of the last 3 episodes I needed to hear was actually released the prior December (remember, I was catching up). So 14 months before taking the exam, ChooseFI released what I was hearing 2 months prior. What was it about?

Go for it

This was one of those actionable messages in which I said, “I’m going to do that. I’m starting on that today.”

The guest was Bradley Rice. And his story gave me hope that that I can still start something new.

Remember my drive to learn? That’s well and good to have it. But it needs an outlet. Preferably one that can be marketed. And what I heard from Bradley was exactly that. A new world to conquer, along with an opportunity to combine the new skills with my Business Analysis background in a way that is challenging and opportunistic.

Personal Goals

The reason Bradley’s message resonated with me is how well it lined up both my experience and with my hopes and dreams. I have a goal of putting my daughter through college. I have a dream of working from home. And although I’ve worked remotely for clients, that work was actually performed in an office 50 minutes away. I have a vision of a sustainable business that I can run from anywhere. But getting the clients has been a challenge.

The story Bradley told answered all of those goals, hopes, dreams and visions, and a few more that I’ve not mentioned here.

Beginning To Learn

Bradley described enough of how to get involved with Salesforce that I had all the knowledge I needed to get started – or so I thought. There’s more to learn than I had imagined.

The first step is signing up on the Salesforce training platform, Trailhead. This is amazing because it allows up to 10 fully functional training copies of Salesforce to be used as a playground for all of your training. And if you need to, you can delete the older ones and spin up new ones in just a few minutes. Plus the cost was a very prohibitive $0.00.

The training materials walk you through everything. There are career and certification paths defined for administrators, developers, consultants, architects and partners.

Trailhead gamifies the learning process. Each module has a maximum number of points for completion. Badges can be earned associated with specific skills, and you can collect points and badges as you move from Scout to Ranger.

During this phase of my learning, I discovered Superbadges on Trailhead. These are the secret sauce for learning Salesforce. Superbadges are real world scenarios in which you must demonstrate that you understand how to perform a complex function, such as establishing security, building a platform or even writing APEX code. Where other badges walk you through doing a few simple tasks, Superbadges give you the requirements and you have to apply what you’ve learned. One of the Superbadges (Billing Specialist) required stringing together about 10-12 steps, in the correct order, to complete only one of the 10 challenges, so they can be very tough.

Superbadges have the added benefit in teaching how to research Salesforce. Since the answers are not apparent by any means, you need to look through all the documentation available on-line. Being able to research is a key skill that I have as a Business Analyst, so again, Salesforce dovetails nicely with my experience.

My first three Superbadges were Security Specialist, Lightning Experience Reports and Dashboard Specialist (Lightning Experience refers to the latest-greatest technology for building applications on the Salesforce platform) and Business Administration Specialist.

There are even some non-Salesforce topics included, such as resume writing, management philosophy based on Drucker, meditation, health and wellness.

Within about 2 months, I had devoured the Trailhead material for Administrators and was ready to prepare for the certification exam.

Final Preparations

In addition to the hands-on experience provided through Trailhead, I joined a group Bradley formed (Learning Salesforce and Building Your Talent Stack) that helps people navigate their Salesforce career transition. From there, I heard about a second source called, which provides sample exams and preparation guides for about $19.00 each – still a great bargain.

Going through FocusOnForce provided me with a better understanding of the philosophy behind Salesforce. Where Trailhead showed me what to do, FocusOnForce taught me how to think.

So in February, I signed up to take the exam, and passed.

Leveraging the Investment

A funny thing happened shortly after certification, a little thing called Covid-19. Now all of a sudden I have a lot more competition for Salesforce jobs. So how do I overcome that added obstacle.

Well, frankly, I’m still working on that obstacle. But here’s how I’m tackling it.

First, I didn’t stop at one certification. There’s a related certification called Platform App Builder which expands on the ideas discussed in the Administrator training.

I already had a pattern for learning. I just needed to cover the additional material and sit for the exam. I finished this exam in April.

Additional Superbadges were also attained. At this time I am up to 8 total.

Team for Travis

Second, I knew I needed to get hands on experience. So I volunteered. Yep, while needing a job as much as anyone else during the pandemic, I volunteered to help a small Non-Profit navigate through the process of migrating to Salesforce. You’d be amazed how many opportunities come because you showed you care.

This gives me the opportunity to demonstrate that I can not only do the work required for a new installation, but it helps show that I can lead, train and coach others on the Salesforce product. There are several platforms set up to help connect non-profit organizations to professionals willing to help. Among them are Taproot and Catch-a-Fire.

I applied for a pro-bono position through Catch-a-Fire for a new Salesforce implementation. I liked that because it was completely fresh, which I felt would allow me to use both my Administration and my Analysis skills. After talking with the founder, we both discovered our stories have several parallels. And the cause was something I felt I could easily get behind. That connection is very important, especially for non-profits and pro-bono work. They want someone who they believe can help them for more than just a gig, to truly help with the organization.

My non-profit is a small organization called T.E.A.M. 4 Travis. This organization is founded by a wonderful parent who lost her son to a rare disease called Asplenia. Travis was a healthy, energetic and happy four year old boy who loved the Texas Longhorns. But the first time he got sick, his body couldn’t fight off the disease due to the undetected abnormality where his spleen did not function properly. Simple testing could have saved his life. Please take a moment to look at this page, learn Travis’s story and, if you can, support this organization.

And it’s showing me that my Business Analysis skills are still very much at work. In the Salesforce ecosystem, Administrators often do double duty gathering requirements for their organizations then building the changes. With the “clicks not code” nature of most of the development, it is quite easy to just build the required changes in less time than it takes to document them.

For example, we are currently discussing various options for documenting contacts made at networking events so that T.E.A.M. 4 Travis can leverage that information in future correspondence. In Salesforce, that is simple, but there are many ways to solve this problem. My BA skills help me find, while consulting with T.E.A.M. 4 Travis which of those ways is best.

Network Strategy – Embrace the Ohana

Third, I am building and expanding my network. I now have long timers in Salesforce who come to me whenever they pass a Trailhead Superbadge! One person has about 10 years experience, and started prior to the existence of Trailhead. So he knows this stuff even though he hasn’t been through the training. But he is very proud to share that he has reached these new milestones.

Salesforce talks about its “Ohana” culture, which embraces traits like helpfulness, involvement and inclusion. It is facilitated through a massive emphasis on Salesforce Communities. Many of these are topical, geographical or skill-set oriented. So I’ve determined to be a joiner.

Once I’ve joined, I’ve observed which groups tend to be more active and that also more closely align with my skills and goals. Then, I began participating (as best as I can while Covid is happening) and connecting with people who can help.

It is very encouraging how many people have been willing to help, giving tips, suggestions and leads. Some have cheered me on saying that I am inspiring them to train more.

What’s Next

I’ll let you know soon enough. But I will say, I’m not done yet.

We Are Neo

We Are Neo

Recently I was talking with someone who is transitioning into Business Analysis. One of the things we talked about is “What other job do you know where you get paid to learn from experts.” Our endless curiosity is met by an endless supply of industries, sectors, changing demands, new technologies, and on and on.

There is another side to that. With that endless curiosity comes an endless demand for applying what we learn – and sometimes for what we have not yet learned. Even for seasoned Business Analyst, there are tools and techniques that we’ve heard of but have not personally used.

And that creates a situation where…

We Are Neo

Who told Neo he could stop bullets?
Who told Neo he could stop bullets?

For example, let’s say a client needs to start embracing Agile but is struggling with a history of deciding everything before the project starts. As an Analyst, you may have worked on many Agile projects, and it’s second nature to you that some questions are not ready to be answered yet.

You do some research in the Agile Extension to the Babok Guide and discover a technique called “Real Options.” But you’ve not used this technique yourself.

What do you do?

You sit in the chair had have one of your Ebenezzer crew-mates plug you in to the “Real Options” program. A few minutes later, you know the pros, cons and concepts associated with using this technique.

Actually, that often is not as far off as it sounds. Oh, we don’t have a portal to plug into the Matrix. But we do have tons of articles, books, blogs and videos we can search.

The Choice Between Two Mindsets.

There’s a couple of ways you can look at what I just described. The first way is through the lens of “Imposter.” How can I claim to be something I’m not? They will see right through me.

The other way is through the lens of “Owner.” If I don’t do this, no one else can or will. Let’s try this and see if it works. If it doesn’t, we’re no worse off than we are now. And this stretches my wings as a leader for our organization.

To move forward we have a mindset that it doesn’t matter if I know it already or not. It’s my job to find the answers, not to have them already. So let’s go.

Consider this famous quote from Richard Branson:

If somebody offers you an amazing opportunity but you are not sure you can do it, say yes – then learn how to do it later!

— Richard Branson

There is a difference between this quote and what I’m describing. It isn’t always just presented to us. As Business Analysts, it is often presented BY us.

Three Factors in Choosing the Best Technique

Three Factors in Choosing the Best Technique

In Agile, many techniques can be used to improve different aspects of the processes. Many of them may on the surface appear to be similar in purpose. But when you look closer, there may be a distinction that favors one over another for specific situations.

So, how do we determine which technique is appropriate to address the specific issues we are seeing?

When deciding which technique to use, the three factors I look at are the Horizon, the Audience, and the Context.


In other articles, I’ve talked about the Three Horizons – Strategy, Initiative, and Delivery. Understanding which Horizon we are dealing with impacts which set of techniques is available.

Some of the usefulness of some techniques spans across all Horizons. Others may be in two or only one. Appropriate understanding requires understanding the purpose of each Horizon, remembering that a Horizon is not so much a time frame as it is a level of decision making. Decisions can impact an initiative from any of the Horizons.

For example, if a project is actively being developed, the Strategy Horizon can realize there needs to be a change in direction. Just because we are actively delivering the product does not mean Strategy has ended. In Agile, all three Horizons can be active simultaneously.

And that feedback can go both up and down through the Horizons. So understanding which techniques are appropriate to each decision-making level – to each Horizon – is essential.

Below are 4 charts which identify the various techniques as well as which source they are discussed – the Agile Extension or the BABOK Guide

Techniques for the Strategy Horizon
Techniques for the Initiative Horizon
Techniques for the Delivery Horizon
General Agile Techniques


Next is the Audience. Answering the question of “Who,” the Audience can be condensed into two broad groups:

  • Part of the team
  • External to the team

So, Who is the Team?

In Agile, the team is considered to be those involved in identifying and delivering a solution to a problem. The team may be further broken down to those working at a specific Horizon – for example, those working with organizational strategy are part of the team, but they are not delivering the product. One would be the Strategy Team, the other the Delivery Team. But for our purposes, that distinction is covered when you consider the Horizon in choosing a technique.

Those that are external to the team is everyone else. External to the team can include individuals such as Customers, Subject Matter Experts, Vendors, Regulators. These would be anyone who is both interested in the success of an initiative, but not involved in bringing the project to life. And they may or may not be part of the organization.


Now we are getting to the heart of the matter – why do we need this technique. Context is another way of asking, “What is the purpose?” or “What do I hope to achieve?” It is the “Why” of the decision process.

There are five categories of Context.

  • Communication
  • Process Analysis
  • Product Management or Refinement
  • Requirements Management
  • Understanding Your Customer

So let’s look at each of these.


Techniques that fall into the Communication context when, not surprisingly, the point is to communicate information. The receiver of the communication is determined by the Audience, which I mentioned above.

Some examples of Communication techniques would be things like Planning Workshops, Portfolio Kanban, Visioning, Retrospectives, Backlog Refinement, and Reviews.

Process Analysis

Process Analysis involves looking for ways to improve processes. This may be processes involving the team, or in the solution itself.

For example, a Process Analysis may find gaps in the solution.

Another example, Process Analysis may reveal that the team is getting bogged down at a certain point in delivery. Perhaps the team needs to adjust to prevent that from continuing.

Some examples of techniques useful for Process Analysis include Value Stream Mapping and Impact Mapping.

Product Management or Refinement

Here we are concerned with delivery schedules or other items associated with defining the product. These answer questions like:

  • What is necessary?
  • When do we make a decision?
  • How does this align with our objectives?
  • When will features be delivered?

Examples include Minimal Viable Product, Product Roadmap, Purpose Alignment Model, Real Options, and Kano Analysis.

Requirements Management

For Requirements Management, the concern isn’t the requirements themselves so much as how they are collected, sequenced, reviewed, prioritized, or refined. For analysts involved in Agile, this can be a large portion of the work.

Several examples of this context include Relative Estimation, User Stories, Job Stories, Spikes, Story Elaboration, Story Decomposition, Story Mapping, and Behavior Driven Development.

Understanding Your Customer

The context of Understanding Your Customer involves techniques in which details about the usage or motivations can be conveyed to the team. Many times, understanding the motivations can have an impact on the final design.

Some examples include Personas, Storyboarding and Value Modelling.

Goals of Agile Analysis at the Delivery Horizon

Coming into Delivery, the Strategy has identified a need to be met, and the Initiative Horizon has identified a solution and its features. When working as an Analyst in the Delivery horizon, the key is to expend the least effort to discover information and support informed decisions about the solution.

I’m sure you realize it is not easy.  It requires a great understanding of what information is useful for decisions on the solution, as well as how to find quickly, and present it in a timely, understandable fashion.

Someone introduced me to the concept of “Planned Spontaneity”  That is where the person has things set up so that if they want to go on various kinds of excursions, they always have bags and supplies packed and ready to go. It takes a lot of planning to be spontaneous. Or, as Rod Stewart used to sing, “Her adlibbed lines were well-rehearsed.”

So when this “Challenge” involves the least amount of effort, I think that also consists of a lot of planning to make it happen, so that the work at the time it’s needed is minimal. To do this, the Delivery horizon addresses two questions. First, looking at the unfinished but defined backlog, the Analyst asks what has the highest value. Then the delivery team asks how to deliver value most efficiently, with the least waste.

A Ready Backlog

Agile Extension to the BABOK®  Guide – section 6.3.1

In the Agile Extension, there is a discussion of how to know when a requirement is ready, as well as when do you need to have it available.  On the first of these questions, the Extension talks about “Invest” criteria.  For now, we’ll say Invest stands for “Independent, Negotiable, Valuable, Estimable, Sized Appropriately and Testable.” I intend to get to the techniques later and will elaborate more at that time.

Whether you are talking about User Stories or other formats for requirements documentation, the INVEST criteria work well.  The point is that the requirement is well constructed with Clear and Concise acceptance criteria and is achievable and Desired as shown in Prioritization

For the second question, sometimes the requirements should wait and be ready in the near future. Agile suggests having things prepared for near term development. If something has to wait, then having it ready now is wasted effort, which takes away from the closer requirements.

Additionally, some frameworks offer suggestions for how far ahead to finalize requirements, so that you don’t rewrite the requirements as better understanding surfaces.

Prioritization and Sequencing

Agile Extension to the BABOK®  Guide – section 6.3.2

The next element of the Delivery Horizon is Maintaining the Backlog. Here we work with the Product Owner to Set priority and sequence to deliver value quickly. The purpose is to support near term development, and the outputs are decomposed features and refined requirements.

Supporting Delivery

Agile Extension to the BABOK®  Guide – section 6.3.3

The Agile Analyst’s efforts prevent obstacles in several different ways, such as facilitating a better understanding of dependencies, coordinating efforts with other groups, and removing roadblocks.

How do Analysts remove Roadblocks?

This question requires an understanding of the Analyst’s role versus other leadership roles on the team. Then, within the Analyst role, what are the roadblocks that can occur.

The first one is a lack of understanding. If the team does not understand, it will cause churn or will prevent the story from being worked.

Another is the interrelationship between features internal to the solution.  Without these interrelationships being understood so that proper sequencing can occur, you may be trying to develop against something that doesn’t exist.  So when it’s delivered, there’s no way to know if it works.  Remember, we’re delivering working software.

Another is external dependencies, which are much like what was just discussed.

Ensure Learning Happens

Agile Extension to the BABOK®  Guide – section 6.3.4

Next, there is Ensuring Learning Happens in the Agile Context, and in this, we first are talking about Processes. By Processes, we are talking about how the team works, not how the process works, or the stakeholders will use whatever is being delivered. 

The team is observing how well they are working, and can they work better.  These observations include feedback to the Initiative or Strategy Horizons because they need to know how to help Delivery better.

The other learning involves the product itself.  Constant feedback determines whether the value is being delivered and the expected results met.  This feedback may affect prioritization and also other horizons. Here is one of the distinctions between Agile and Waterfall – that feedback from Delivery can affect the other horizons. Waterfall would say, Delivery is the result of planning, so there’s nothing that goes back in time to fix what has been done.  Perhaps that’s a bit oversimplified. The Agile Mindset recognizes this project is not performed in a vacuum.  The speed of delivery affects resource availability for other initiatives and other needs.

Focus on Vision and Value

Agile Extension to the BABOK®  Guide – section 6.3.5

Finally, there is Maintaining Focus on the Product Vision, Customer, and Value. The Agile Analyst’s work continually promotes a shared understanding of how the work achieves the vision. Focusing on value means the most valuable things are prioritized and delivered early.

The Will to Overcome All Obstacles

About two years ago, I started on a journey that has changed my perspective on everything. At that time, I was overweight and had just come out of pneumonia, followed by the flu, back to back. I was disengaged from my family because I was constantly tired. And I decided it was time to do something about it.

I read about Keto and decided to try it. I added up what I ate every day and it was atrocious. I cut out all fries and sugary sodas, which cut my caloric intake in half. I cut carbs 80%. And I did full fasting once or twice each week.  Within three months, I lost 30 pounds. I felt great. My mind was alert. I was not tired anymore. That’s where the story begins.

Then came the obstacle — a huge one.

The Obstacle

I have had a problem with my gallbladder for a long time, so this isn’t Keto related. But it was time to do something about that too, and I had it removed on May 8, 2018. Later the doctors would speculate that a gallstone must have escaped during the surgery.

A week after the procedure, I started having complications in the form of violent pain and nausea. I went to the ER, who treated both symptoms and sent me home. And I returned the next night with the same signs. I was admitted to the hospital this time.

It turns out that the escaped gallstone had found its way into my pancreas and blocked a duct. That means the enzymes produced had nowhere to go except back into the pancreas. It was eating itself.

While in the hospital, I was also diagnosed with two blood clots.  One was in the leg, the other in the lung. This created all kinds of problems as treatment for one could not interact with the other.

For pancreatitis, they pumped fluids in me. The 30 pounds I had lost was put back on me in 2 days. The fluid was to keep my blood pressure up. Pancreatitis patients can die from low blood pressure as the body attacks the issue by diverting blood to the organ. I had six IV bags going at any one time.

Then the hiccups started. Uncontrollable. I couldn’t rest because of them. For days, every 20 seconds. And the staff all but laughed when I asked if there was something they could do about it. They did say to hold my breath or drink from the wrong side of the glass.

Lack of Trust

So I had a trust issue with this team. Some of the doctors included the same team that performed the surgery. I was in the same hospital that sent me home from the ER only to return the next night. And the physicians were telling me one thing but the staff something else.

On the 3rd night, I moved into a standard room. It was tiny, with a slit of a window positioned in the wrong corner so you couldn’t see out of it. I think Johnny Cash “heard a whistle blowing” through that window that allowed no “sunshine since I don’t know when.” It was depressing.

I assured my family it would be OK for me in that room. But after they left, I had a lot of time (between the hiccups) to think. Am I dying? What will happen to my family if I do? And I resigned myself to trust God to work out whatever my family needed, whether I make it or not.

Get Out NOW

About 2 am, I heard His response. It was so jarring when I heard it, but gentle at the same time. “Bill, you’re the project. This leadership team doesn’t know what to do. Get out of there before they kill you.”

All of a sudden, it made sense. God speaks to you in the language you understand. God was making it known that He was not done with me yet. Let that sink in a bit. I knew I was going to make it. In addition, He was reminding me that when project leaders do not know the way, the project always fails. And if I am the project…with this leadership team, I was going to die. Change the team NOW.

But I’m in a hospital bed with 6 IVs. I can’t just walk out. Somehow I had to get out.

I texted my wife, Kimberly. It was about 2:00 am. She was up trying to research everything she could. I told her to get me out and, they’re going to kill me if I don’t get out of there.

She contacted the hospital immediately and initiated the request for a transfer. We asked to transfer to either of two hospitals in Lexington and eventually got accepted into Good Samaritan, which is part of the University of Kentucky. It took until 6 pm to get the transfer on the road.

I would spend the next 2+ weeks at Good Sam.

Now I refer to this transfer from the local hospital to Good Samaritan as the time I fired the hospital.

A New Team, A New Vision

At Good Sam, they did the opposite of everything the previous hospital had done. They outlined a plan to me within an hour of my arrival and stuck to that plan throughout the stay. They took the fluid off (which required countless trips to the bathroom). They treated the hiccups (and replaced it with bathroom trips). And they paid attention to everything.

Between both hospitals I went probably a 10 days without any food. For a time, the only liquid was through the IVs.

The Damage is Done

Kimberly did not share her research with me until later. She found, among other things, an article called “The Atlanta Classification for Acute Pancreatitis.” This article outlined mortality rates for Walled Off Necrosis and explained that the best treatment is not to treat it. Any effort to drain the necrotic material risks infection. And because there are no surviving blood vessels through the necrotic material, there is no way to get antibiotics to treat any infection.

The damage to my pancreas is severe. 70% of it has been liquified – a condition called Walled Off Necrosis. I became a type 3c diabetic, insulin-dependent and requiring digestive enzymes.

The Importance of Kindness

Dr. Calder was finishing up his residency at UK that month. I was one of his last patients before he finished. Several times, he wheeled me out of my room and ate lunch with me. I still get emotional thinking about that simple kindness.

I finally made it out of the hospital. I walked around the yard. Then twice around the yard. Eventually, I returned to work.

I lost another 20 pounds after leaving the hospital. So that means I lost 30 over three months before the surgery, gained 30 in two days, lost 30 in 2 weeks, then lost an additional 20 over the next two months. Now that I’m diabetic, I do not try the Keto diet. That does not mean I’m against that diet, just that my organs already have some extra strain so I choose to be more normal.

The Importance of Community

But the obstacles were not done. Every demon tries to kick you one last time as it is banished.

Back in May, just before the surgery that started all this, several people were let go from work. Our staff of Business Analysts was cut from six, counting the director, to three. About two weeks after returning, I also was released.

One of my friends, Richard, who had been released in May, provided me contacts for jobs he had worked. So, I landed a new job without missing a paycheck.

Between my family, Dr. Calder, the staff at Good Sam, and Richard, I owe so many people so much.

Full Recovery

When you look at me now I look and act as healthy as most people. I have more energy than most. My mind is sharp. The only difference is that I must know how many carbs I am eating so that I know how much insulin to take. As long as I know, like most diabetics, I can eat what I want. With that in mind, I also have to know if my blood glucose is high or low, so I can adjust my insulin dosage accordingly.

If you see me jittery, that means I’m running a bit low and I need something with sugar in it. I have a built in excuse for junk food. But really the best thing is 100% juice with the sugar.

At the beginning of this article I talked about how this medical event changed everything. Since the medical event:

  • I started taking the stairs at lunch. In December 2018, I was able to climb up to 21 stories. Not bad considering the building was only seven stories, and I could barely walk around the yard in June 2018. No one else was doing that in the building.
  • I understand how viewing things through a project lens can illuminate the need for change. I believe God used my project oriented mind to save my life. If you think that is exaggeration, then read this again.
  • I am grateful for simple things. I do not want anything fancy at all. I just want things to work. Simplicity is the key to abundant living.
  • I’ve completed my AAC certification from IIBA and my PSM-1 certification from And I’m currently working toward Salesforce Administrator. This is on top of my CBAP certification from IIBA.
  • I’ve developed a course to teach AAC certification to other Business Analysts. The course has caused ripple effects in my local IIBA chapter, causing a change in approach to other certification courses. (See, this article is relevant to Agile Analysis).
  • I started this website, and in doing so, I taught myself WordPress and took some courses on writing. Related to that, I revisited a course on Web Development.
  • I’m working to improve family relationships that were damaged through my neglect back when I was fat.
  • I have convinced my family about changes we all need to make for long term financial stability.
  • I am always aware of my health. I’m not obsessive about it. But I have to test between four and six times each day, inject insulin with meals and bedtime, and take enzymes with meals. With that kind of regimen, it is impossible not to be aware.
  • I realize the importance of being your own health advocate. I know that you must make people listen when it comes to your health. I’ll never know how much less damage there would have been if the ER admitted me the first time. DO NOT BE AFRAID TO FIRE THE HOSPITAL. I DID.
  • I have had a personal revival of faith. Although I had never walked away from my faith, I had gone through the motions there for too long. I am currently reading the Bible through for the second time since the medical event, this time my goal is in 4 months. And by reading larger sections at a time, I am making connections that I had missed before.
  • I am constantly listening to podcasts that inspire and educate me toward goals I am attaining. My favorite is ChooseFI, which I’ve binged in it’s entirety, and talks about everything, not just finances. Between that, my family and my faith, I consider this one of my major sources of motivation.

I’ve been told to never make more or less than three points. I just blew up that rule. That’s twelve different areas of improvement in about 18 months.

Summing it up. I no longer neglect my family relationships, my faith, my health or my career. I thought I was taking care of family and career before. Now I am seeing how much more I can and will do on all fronts.

Do I want my pancreas back? You bet. Am I better off now than before? If that is still in question, then read the last section again. Because…

Obstacles are there to make you better in all areas of your life.

If there is anything to take away from this story, I hope it is one of these three ideas.

  • Simplicity is the key to abundant living.
  • Be a vocal advocate for your own health, even if it means overriding what professionals say. Don’t be afraid to “Fire the Hospital” if you have to.
  • Obstacles are there to make you better in all areas of your life.

Goals of Agile Analysis at the Initiative Horizon

From the Strategy Horizon, we understand the overall purpose of an initiative and its intended impact. But there is a lot that remains undetermined at this point. The initiative may have the organization’s backing, but that doesn’t define exactly how it will work, what resources are involved, or how much it will cost. The role of the Initiative Horizon is to fill in those gaps, report back to the Strategy Horizon for decisions to continue or end research, and potentially provide the requirements to the Delivery Horizon.

So, look at this in more depth.

Identify Solution Options

Agile Extension to the BABOK®  Guide – section 5.3.2

One of the primary functions of the Initiative Horizon is to identify options that can potentially meet the organizational need determined by the Strategy Horizon. Implied in this is that there are options – more than one – which have that potential.

In determining these options, a clear understanding of the Strategy Horizon’s intended purpose will have to be established. If that has not happened, the analyst will gain clarification from the decision-makers in the Strategy Horizon. To eventually bring the desired results, clear and measurable objectives are communicated and evaluated here.

We need to consider “what is the shared understanding?” and “what are we assuming?” For example, one assumption may be that there is an affordable, workable solution. The analyst will need to discover if those assumptions are correct or not. If not, then that option will cease to be considered, and that result communicated to decision-makers in the Strategy Horizon.

Other considerations include “What could cause the project to fail, a delay, or a limited function?” To address this, the analyst needs to understand from a high level, what this optional solution does, and what constraints would make it not a viable solution. For example, a vendor product may meet the need, but it may not work in our environment.

Identify Components

Agile Extension to the BABOK®  Guide – section 5.3.4

Another element of the Initiative Horizon is identifying the components needed by the stakeholders and collecting information about its effect on the need, costs, and constraints. Collect enough detail to make informed decisions without wasting effort by going too deep.

The components are something that is reviewed and revised periodically though the duration of the initiative. Also, the components may be identified for all of the options, not just the one eventually chosen. This is because part of the decision will involve which features are included and how much effort those features require.

Size of Items

To determine the size of the items requires that the components are identified. These will often be referred to as Features. Each component needs an approximate size reflecting the expected work effort involved. At this point, it is a very high-level estimate.

Prioritize Components

Agile Extension to the BABOK®  Guide – section 5.3.5

Agile Extension to the BABOK® Guide – section 5.3.5

With those components identified, we need to determine the priorities and sequence components. This will be revisited often and influenced by feedback both from Delivery and Strategy

Prioritization can be impacted by several factors, such as the impact of the feature, cost, how the project is progressing, multiple levels of feedback, and others.

Features may be prioritized for options before a specific solution is chosen because the scheduling of resources required to bring prospects to reality will need to be discussed. Schedule constraints could tip the scales of one option over another.


Agile Extension to the BABOK®  Guide – section 5.3.3

In recommending an option, a simple way of looking at it is, “Which option gives the most for the least and still meets the need and constraints?” To decide that, we don’t need to know everything, but we need to know enough. And since we’re evaluating multiple options, we need to be consistent in what we use to make the decision.

To make the recommendation, confirm that our assumptions are valid. These could be organizational assumptions or assumptions about a 3rd party entity or product. We will need to see:

  • How difficult is it to do what this option requires to get it live. 
  • Are the impacts on the organization, either intended or not intended? 
  • How well does it meet the need? 
  • How high of a price?

Determine When Need is Met

Agile Extension to the BABOK®  Guide – section 5.3.6

The role of the Initiative horizon does not stop at determining a solution. It continues while the product is being delivered to determine when the need has been met. Again though, this is based on analysis, which leads to a recommendation. The ultimate decision does not belong to the analyst, but a responsible decision-maker or decision body.

Each delivered feature is an opportunity to determine if the need is met if more is required if changes are needed or the project canceled. The intent is to avoid waste by only satisfying the need identified by the Strategy Horizon.

Assess Viability

Agile Extension to the BABOK®  Guide – section 5.3.7

Along with determining when the initiative has met the need, a counter analysis also continues concerning the initiative’s ongoing viability. By viability, that not only means whether to continue the initiative, but also whether it needs to be altered in some way.

Agile is called agile for a reason – because it is built to handle change. So we have three options: to Continue, Change, or Cancel the initiative. The basis of that assessment is several factors that constantly change, such as the realized impact, success measures or KPIs, remaining work, constraints, feedback from delivery, and strategy.

How to Avoid Delegation Through Abdication

How to Avoid Delegation Through Abdication

As I am writing this, I have recently finished a panel discussion on Agile Transformation given at my IIBA Chapter. One of the recurring themes of any discussion involving Business Analysis is stakeholder engagement. Lack of stakeholder engagement shows up in a myriad of ways ranging from indifferent behaviors to actual hostility toward anything involving an initiative. It is almost impossible to discuss without this subject surfacing.

One of the most common forms in which stakeholders are not engaged can is Delegation Through Abdication. To give credit where it is due, I am borrowing this term from Larry Hagner, who writes a blog called The Good Dad Project. I think it originated with The E Myth Revisited, by Michael Gerber.

Delegation Thru Abdication occurs when you feel overwhelmed by a subject and want to avoid it in any way possible. Perhaps you’ve been burned in some way. Or you have no vision for it. So you hand it off to someone else. Someone who really should not be responsible for the decisions, or should not be solely responsible for it. So you send representatives to do your job.

Does this sound familiar?

The problem doesn’t go away. If anything, it usually gets worse because, although the delegate may end up handling things wonderfully, the more common scenario is that they don’t. And even if they do knock it out of the park, there’s still the emotional side. You know you’ve compromised. They know you’ve compromised. They’ve lost respect for you. And you’ve lost respect for yourself.

One of the things I’ve learned in Business Analysis is that you cannot make anyone do anything they don’t want to do. The motivation must be within them to do it. But we can encourage that motivation to the surface and grow in strength.

I mentioned motivation, and that is what we need to explore. What causes the behavior? Why does this person want to avoid it?

I have often said when giving talks or teaching that Business Analysis does involve a fair amount of psychology to understand the motivations of stakeholders and help them understand their fears. Those fears represent concerns that need addressing as the project unfolds.

I find that merely asking the question “Why” often opens up the conversation to valuable input for the project. This happens in 2 ways.

The first way is to identify whether the fear is realistic or not. There’s no telling how much we worry about things that will never happen. So having someone with some objectivity to look at the concern and evaluate it can be helpful to let the person go past the fears.

The second way is through mitigation. And this truly is the point of this article in the first place – because someone was abdicating their decisions to someone else, requirements are missed. That creates a self-fulfilling prophesy – “I told you it would never work.”

Of course it doesn’t. Absence sabotaged it.

As Business Analysts, we see that stakeholder engagement is one of the most significant risk factors in project success. I believe it is as essential as the quality of the delivery team. Without that engagement, people will not be able to determine what is needed.

Whether these concerns are realistic or not, they are addressed initially by identifying them. As the saying goes, “A problem identified is half-solved.” The answer can only come once the question is asked.

So, if you want to avoid Delegation Through Abdication, start by asking, “Why do you want someone else to represent your interest?”

Goals of Agile Analysis at the Strategy Horizon

When an Agile Analyst is working on the Strategy Horizon for an organization, the purpose is to provide information to decision-makers that relate to organizational goals. This requires a shift in thinking from the analysis performed at other horizons. The shift is partly due to the purpose of the Strategy Horizon, and partly complexities of this early stage. With such complexity, the Agile Analyst needs to have the following in mind.

Breadth of Information

Agile Extension to the BABOK®  Guide – section 4.3

Agile Extension to the BABOK® Guide – section 4.3

I think it should be evident that the Strategy Horizon involves a broad spectrum of interests and concerns. The details are often revealed in the other horizons. However, that does not mean this Horizon is not substantive. So let’s look at the areas of concern for the Strategy Horizon.

In the Strategy Horizon, one of the first things needed is communication channels that receive and give appropriate information across the organization. Items discussed in the Strategy Horizon may affect the entire organization either directly or indirectly. Decisions and discussions may or may not involve a specific operation, but they will impact resource allocations and priorities.

Observations about market changes and trends are evaluated to determine changes in product, features, or the importance of a proposal.

From the external environment, technical or competitive advantages or disadvantages may be leveraged or mitigated appropriately. Changes in societal expectations may also affect the product, and it’s design, features, or priority.

Additionally, internal changes may affect the strategy. For example, changes in the leadership’s vision for the organization may move high prioritized items to non-starters.

Even though we are in the Strategy Horizon, the organization assesses impacts based on feedback from both the Initiative and Delivery horizons. The apparent effect is estimations and projections for projects and required resources.

These play a part in fulfilling the intended purpose of the Strategy Horizon – to prepare the organization to counter a threat or capitalize on an opportunity. Those threats and opportunities should be revealed through the items discussed previously.

Maintaining High-Level View of the Information

Agile Extension to the BABOK®  Guide – section 4.3

For those who have been heavily involved in delivery, there’s a shift in how you approach problems in the Strategy Horizon. That shift in thinking affects the level of detail. So, what level of detail should we view at Strategy?

Here are a few considerations:

  • We aren’t yet ready to get too deep in the weeds. By that, I mean specific items describing the solution. At the strategy level, we don’t care about defining the solution.
  • We are concerned about identifying potential needs. Notice, these are potential needs. They may never be actual needs. An identified risk may never happen, but we need to identify it and think about mitigation against it. An opportunity may be on the verge of appearing, but not quite come to the demand levels or cost levels to make it profitable.
  • We are clarifying the need. The solution will be dealt with in the Initiative Horizon. So, all information that tells what we are trying to accomplish, not how to achieve it, begins at the Strategy Horizon.
  • The focus is on organizational risks, changing priorities, or other conditions and identifying new needs.

Making the Complex Simple

 The ability to take complexity and make it simple is the key to effectiveness as an Analyst on the Strategy Horizon. This ability will likely drive success in the Strategy horizon.

One could ask the question, “What are the indicators which show we need to take action in this area?” Then, “How do we get the information to monitor those indicators?” It sounds like a simple set of questions. But the reality is, there is much uncertainty with the information – especially when it is based on external sources. Add to that, the level of complexity, and the quantities involved.

The Agile Business Analyst will make models to simplify the decision-making process using the information from all relevant sources.

The Three Horizons

When we think of Agile, we often think of solution delivery.

One of the things I’ve observed about IIBA is that it looks beyond the boundaries of the delivery functions. The Business Analysis certifications look before and after the project, to identify activities leading to and resulting from the project.

Agile Analysis is no different. Here, we are looking at what goes on from the very beginning of an idea, through to its delivery. So, IIBA has identified three horizons – Strategy, Initiative, and Delivery.


  • The three horizons allow the organization to have a framework for response.
  • Having multiple horizons identifies the stages and shifts in focus that occur as an initiative matures.
  • To explore the interplay between each Horizon and how they inform each other.
  • To understand a fuller impact on the organization. This gets into why we are doing things in the first place, instead of merely what are we doing.

Strategy Horizon

The Strategy Horizon takes the broadest view possible, looking at the organization as a whole. Decisions made here support organizational strategy and resource allocation. We are identifying opportunities such as products, services or initiatives, or areas of risk and ways to mitigate against those risks.

Risk at the strategy level is different than at delivery. Here we are thinking of risk to the organization, not the project. These risks can include:

  • Regulatory Changes
  • Competitive Landscape changes
  • Disruptive business models that undercut your revenue stream
  • Public Relations issues

At the Strategy level, we are concerned with the overall organizational strategy. With that kind of a view, a strategy is never talking about the immediate term. It takes time to analyze, theorize, confirm, and set a vision for an initiative. Add to that the time to deliver it.

Initiative Horizon

Moving on to the Initiative Horizon, here we become more focused on a goal, initiative, or a team.

So, when I look at this impacts list, and I see a goal vs. an initiative, there’s a distinction. At this time, the purpose has likely been identified, but the means to achieve it has not. So, there needs to be a decision process to determine the solution. That solution becomes an initiative and is further refined until a decision is made to deliver it.

Just because something is in the Initiative Horizon does not mean there is ever an intent to act on it. The same can be said about strategy. But it is a preparation and exploration horizon.

Initiative based decisions include: 

  • Identifying how to meet a goal, which becomes an initiative
  • What is desired for that initiative
  • Identifying needs and options
  • Inform both the Strategy and Delivery Horizons

Delivery Horizon

Decisions made here affect the delivery of a solution and support the delivery time and product.

Delivery also:

  • Identifies the work breakdown, delivery, test and prioritization
  • Focuses on the needs of the stakeholder

3 Planning Horizon

The point of these Horizons is that they are not purely phases or stages. An initiative is not necessarily in one to the exclusion of the others. Instead, influence is bounced between the Horizon as feedback and knowledge are continually gained.

A clearer picture is illustrated below.

Agile Extension to the BABOK®  Guide – section 3.2

As you can see, information is bi-directional. Agile brings news back to the decision-makers from the delivery team. The information exchanged between each Horizon informs the decisions made at the receiving Horizon.

With this level of exchange, the organization goes beyond delivering a solution, to practicing Agility – the application of an Agile Mindset across the organization.

BACCM: Impact on Knowledge Area 6. Solution Evaluation

BACCM: Impact on Knowledge Area 6. Solution Evaluation

This post wraps up this series with a discussion of how the BACCM relates to Solution Evaluation. In its introduction of this knowledge area, the BABOK guide makes an important distinction between Solution Evaluation from either Strategy Analysis or Requirements Analysis and Design Definition – that Solution Evaluation is performed against work that has been done, where the other Knowledge Areas are looking at future work. For this post, when I talk about delivered work, that can be a prototype, beta, product increment, or full release of the product.

Solution Evaluation asks questions such as:

  • Does this do what is needed?
  • Does it perform well?
  • Are changes needed to the work that has been done?
  • Is the need satisfied?
  • Can the need be satisfied?

How does the BACCM interact with Solution Evaluation? The chart below gives a summarized answer to that question.


The Core Concept of Change allows looking at what has been finished and decide that a course correction is needed. That correction could be an adjustment to adjust what has been done, change the future planned work in some way, determine the product meets the need or never will.


All of the analysis is to be measured against the need. There are several factors in this analysis:

  • Changes to the organizational environment, which changes the need.
  • The expense of the solution may be significantly higher than anticipated.
  • The organization may have overestimated their capability to deliver the solution – it may not be possible.
  • The time to deliver may be more than anticipated (likely also reflected in costs).

There are four options which could result from an analysis of these factors:

  • If the delivered work continues to provide hope of meeting the need but has not completely done so, then the project should likely continue.
  • If the delivered work meets the need, but additional features are determined to be valuable, a decision to extend functionality beyond the minimum viable product may be made.
  • Or, if there are no desired other features and the delivered work already meets the business need, the project will end with the delivered work.
  • Finally, if the analysis factors (environment, expense, capabilities, time) are weighed, and the project never will meet the need, it should be discontinued.


It may be a bit redundant, but it is the delivered portion of the solution that is analyzed by comparing it to the need. It may be possible to measure the realized value delivered as compared to the anticipated or potential value that was proposed.

In Agile environments, it is essential not to conflate effort with value as part of Solution Analysis. For example: If I take a job that pays $30/hour and a friend does the same role at another company for $25 – the effort may be the same but the value is not. Value is determined by the benefit received, not the effort used to obtain it.


At some point, the stakeholders will have the opportunity to review the delivered product and determine how well it meets their needs. They will be considering the question of how well it provides value. As an analyst, our job is to help their observations have a voice – determining whether the value is delivered, whether changes are needed, or whether the need cannot be met.


Here again, we need to recognize that need is only half of the value equation. From a financial standpoint, value = benefit – cost, where the benefit is the monetized representation of the need. There may be other ways to determine value based on some non-financial considerations, such as regulatory compliance. Yet still, when we consider value, this goes beyond merely considering the need.

Before the work, there probably was a determination of how much benefit would be received and an anticipated cost. So the Core Concept of Value measures that prediction against reality.


Previously we mentioned that a change in the organization’s environment might also mean that the need has changed. Several organizational factors may be in play. This may include any of the following:

  • External factors, such as changing public opinions or values.
  • Regulatory changes may alter what is required.
  • Organizational changes, such as changing corporate purpose, leadership, structure or viability.
  • Technological changes, such as new publicly available services.
  • Competitive changes where a competitor enters or leaves a market position.