Skip to main content

Author: Paul Mulvey

Green Eggs and Ham – a Study in Change Management

“I am Sam. Sam I am.” For those of you who are unfamiliar with the quote, it comes from the book Green Eggs and Ham, written by Dr. Seuss. According to Publisher’s Weekly in 2001, it was the fourth-most popular children’s book of all time. That would lead me to believe that most of us have either had this book read to us in our childhood or have learned to read from this book (some, like me, still read it today). We have been indoctrinated at such early ages to accept change, so why do so many of us react badly towards change? After all, Sam has a mission, and that’s to get the unnamed character to change his behavior. Perhaps, though, if Sam went about it a little differently, we would never have had the book after all.

As BAs, we are often in the middle of changes – application changes, process changes, organizational changes. Let’s see how Sam handles a case of change management, and see if we can learn from his mistakes.

1. Failure to plan the change

Human beings are complicated people (even those asexual creatures in the Dr. Seuss books). Sam barges in and starts announcing something new and expects that our friend will embrace it as much as Sam does. It’s clear that Sam wants our friend to eat the green eggs and ham, and probably thinks that eating them is great, but Sam’s expectation is that our friend will partake of the new treat. It seems that Sam’s strategy is to offer so many ways to eat green eggs and ham that our friend should just change and do it. Consider that it’s not until 7/8 of the way into the book that he finally asks if our friend would just try them. If that strategy to “just try them” was planned at the beginning, the change implementation might have gone better.

2. Failure to communicate the reasons and expectations behind the change

It’s no wonder that our friend who is having green eggs and ham is put off by Sam. He barges in with, “I am Sam. Sam I am.” but with no explanation to our friend about the change. It’s no wonder that our friend is turned off and immediately puts up a defensive wall – he clearly has no idea of what is happening. Perhaps Sam could explain the reason why he is offering the green eggs and ham. “Times are tough, the economy is strange, and the cafeteria selections have got to change. Here’s something new, a nutritious meal, it will give you low blood pressure and abs of steel.” If perhaps Sam explained it that way, our friend would have understood the reason behind the change.

3. Sam should have gotten buy-in from our friend

One of the most effective ways to change is to make the person want to change. If they want to change, they embrace the change. If they feel that they are part of the change, and had a stake in it, they will do everything that they can to see it succeed. Why? No one wants to be on the losing side, and if our friend thought that it was partly his project, he will do what it takes to make the change work. Once he feels that it’s his idea, he’ll want to push forward with the change. If Sam had played his cards right, our friend might have stated, “When we serve everyone this food, who will whine? When after all, this idea was MINE!”

4. Roll it out to the influencers

There is always a group that is highly influential in any group, and they set the trend. If you can get them on-board with the change, then the change is far more likely to happen. The fox, the mouse, and the goat didn’t really do much to help Sam and his cause. But perhaps if Sam had brought in others that our friend trusted (the influencers), they would have “sold” the idea of change as beneficial. Influencers can be at any level, and even at the same level of the people that are going to change – sometimes it helps having that peer allied with the change so it doesn’t give the impression that “big, bad, management” is forcing something upon the masses. Why are so many in the United States driving 4WD SUVs to pick up groceries and take their kids to soccer practice? GM and Ford didn’t push that change on them, influencers in society did.

5. There was nothing in it for our friend

How well did Sam communicate to our friend what the benefit was for eating the green eggs and ham? None, as I recall. Sam just prattled on and on about places to eat them and animals to eat them with, but no clear reward or benefit for our friend. When explaining change, explain how it is going to benefit those that have to make the change. How much more effective would it be if Sam had provided an incentive to eat them. Then perhaps the response would have been, “Hand over the plate, and give me a fork. I’ll proclaim their greatness to ALL of New York!” And remember, not everyone perceives the same benefit the same way – you have to figure out what motivates each team member and what each one will consider a benefit.

6. Not involving the people who were going to have to change

It was clear that Sam knew all about green eggs and ham, but how well did he involve the others in the story? Not much. He basically swept in and announced that green eggs and ham were now going to be eaten. And what is our friend’s immediate reaction? “I do not like that Sam I am” Why do you think that is his first reaction? Well, he may have heard rumors about a horrible new food being introduced, and because those involved in the change management (in this case, Sam) have not involved those who had to change, our friend had no clue what the real story was. Think of your organizational – how quickly do rumors spread when there is uncertainty? By the time that the change is announced, the rumor could be far worse than the actual change. By involving the people that are going to change, they can dispel the rumors and help with the transition.

7. Sam should have led the change, not simply ordered it

Sam was not in a position of leadership; he was more in a position of ordering, or “bossing around.” He was so busy telling our friend how many ways to eat the meal, but did not mention that he ate them himself and liked them. If he could give testimony to their quality, our friend may not be as hesitant. Sam may have said, “I had them last night, they’re quite a good meal; my wife and I loved them, and it made my kids squeal.” Or better yet, he could invite our friend to the meal, and they could all eat them together. If our friend sees Sam eating the green eggs and ham himself (thereby leading), our friend may see that the change is good, and find it easier to go along and make the change.

Obviously, Theodore Geisel (aka Dr. Seuss) had no intention of writing a book about change management, and the message really is to try something new because you might like it. But look how often we reject changes and have trouble with change, especially since many of us grew up reading this book (born after 1960, anyway). It’s not that change is bad; it’s just that it fails because of a poorly executed plan or poor communication. So, to sum up:

  1. Plan the change, and how you are going to roll it out to those that will change
  2. Clearly communicate the reasons behind the change and what the expectations are from those that are going to change
  3. Get buy-in from the people that are going to change – when they want it to succeed, they will do everything in their power to make it succeed
  4. Make sure that the influencers are on board
  5. Explain the benefits to those that are about to change
  6. Involve the people that are going to change, and make sure that they know what is happening and when so as to controls rumors and mistruths
  7. Lead the change – be the first person to change when it happens – don’t lead from behind the front lines

Don’t forget to leave your comments below.

“I am Paul. Paul I am.” Paul Mulvey is a Contract Business Analyst currently on assignment at Cushman & Wakefield. His current assignment has him commuting 4 hours daily on a bus from Eastern PA to NYC, and all he does is just sit, sit, sit, sit, and he does not like it, not one little bit. He can be reached at [email protected]

Managing Risk the Tour de France Way

ManagingRisk2It’s the third mountain stage in the Tour de France (TdF). A few riders are in the lead as they wind their way up a mountain. The number of riders in the lead group starts dwindling – 12, 10, then 8. All of a sudden, around a hairpin bend, Jan Ullrich weaves across the road accelerating, pulling away from the pack. What will Lance Armstrong do? Chances are good that the US Postal team has thought about this risk and planned for it. This means that Armstrong will know exactly what to when Ullrich pulls this move, and the team has responded to many other risks up to this point to get Armstrong in the lead group.

Before I “race” into what Armstrong does and how the TdF teams manage risk, I figure that I should discuss risk analysis. Risk Analysis is technique 9.24 in the BABOK v2.0 that you should become familiar with. If you’re not familiar with risk analysis, this is the article for you.

A risk is an uncertain event or occurrence that can have a negative or positive effect on the project team’s ability to achieve an objective.

How do you plan for uncertain events? Through creation of a risk management plan!

The risk management plan includes a list of the possible risks that you may face during the project. You should create this at the beginning of the project, and update it as the project progresses. Each risk should include a description of the risk, the likelihood that a particular risk will occur and its impact, and how the team is going to respond to the risk should the risk become reality. Now because risks are really uncertain events, and uncertainty is just, well, uncertain, you can’t possibly plan for every risk so concentrate on those that are more likely. For instance, if one of your stakeholders suggests that you hold your requirements workshops in the building’s new outdoor garden courtyard, a reasonable risk would be that it might rain forcing cancelation of the workshop; while pieces of Skylab falling out of the sky would not.

Another thing that you need to include in the plan is your team’s Risk Tolerance. This is how much risk can be tolerated, and it may be different at different points in the project. Tolerance levels are: Risk Averse – will seek to reduce negative risks and accepts reduction in potential benefits in return for a more certain outcome; Risk Neutral – the benefit of the risk response must outweigh the “costs”; and Risk Seeking – willing to accept high risks in order to maximize chances of success.

Let’s look at the relationship between probability and impact. Suppose that we come up with a risk that it might rain on the day of our requirements workshop. The probability would be the chance that it would rain. The impact could be high or low depending on the availability of a tent or shelter. Our response could be different depending on how we plan to respond. For instance, we might avoid (hire a company to erect tents in the courtyard), accept (oh, well, we’ll just get wet), or mitigate (negotiate with the stakeholder to host the meeting in the company boardroom instead to lessen the chance of the impact). How do you determine probability? Look at the weather report, or if it’s too far into the future, look at the region. If you’re in Seattle, rain probability is High – Arizona? Low.

At this point, you have a list of events that may occur such as the table below.


Risk Probability Impact Trigger Response
It may rain during the outdoor workshop High Low Begins raining Avoid – we will erect tents in the courtyard garden large enough to house all meeting participants

So how does all this risk management work in the Tour de France?

The TdF is a grueling 2,000 mile + stage race, with twenty teams and 10 riders per team. It takes place over three weeks in July, and the winner is the one with the lowest overall time across multiple individual day races (called stages). Very simple objective – tough to get there.

Each team has examined its own strengths and weaknesses, so they have their own way of approaching the risks that present themselves in the race (you have performed a SWOT analysis, haven’t you?). Let’s look at one team’s stage one risk management plan. No one has started racing yet, so there is no leader. It’s a flat stage so there will be a mass sprint at the end. Your team does not have a great sprinter (your team’s weakness), so you probably are going to consider yourself risk-averse at this point. You don’t want your riders to risk getting caught up in a big crash at the end, ruining those cyclists on your team that are really good in the mountain stages (your strength). So, let’s create a risk. The risk is that your team will likely not win this stage. The probability that this will happen is high because you don’t have a strong sprinter. The impact is low because in this stage, riders will only be seconds apart instead of minutes or hours, and that time will be easily gained in the mountain stages. Your strategy is then to accept the risk. There is no real effort to try and win this stage because you are going to win in the mountains with your climbers.

So, now we’re into week two of the TdF and in the mountains. Armstrong is in first place overall, but there are some challengers who are within striking distance and could challenge him for the yellow jersey (what the overall leader wears in the race). Lance also put in a very fast climb yesterday so he has a two-minute advantage over second place. Will we be risk averse or seek risks in today’s race? Generally, the strategy would probably be neutral – protect the yellow jersey and only attack if the opportunity presented itself. Let’s list some of the risks that may be on this day’s risk management plan.

Risk Probability Impact Trigger Response
Jan Ullrich attacks High High Ullrich accelerates on a climb Mitigate – Armstrong will hang on Ullrich’s wheel, making Ullrich do the work but will not let Ullrich gain time.
Stephane Heulot attacks on the mountain stage High Low Heulot accelerates or breaks away on a climb Accept – Heulot is 45 minutes behind Armstrong in overall time and will not be able to gain that much time on the climb. Armstrong will not win the stage, but will not lose the overall classification. Armstrong will let Heulot get away.
Richard Virenque attacks High Medium Virenque attacks on a climb Exploit – Virenque is an excellent climber, and if Armstrong can force Virenque into the attacking position, Armstrong can ride on his wheel, making him do more of the work while Armstrong still retains the lead in the overall classification.

These are just some of the risks that the race team managers and the riders face every day. They plan for some of these uncertain events and react based on the response that they have planned out. How can you use the lessons from the TdF on your projects?

Follow these three steps:

  1. Think about what uncertain events might arise within your project. Write them down. These are your risks. For instance, one stakeholder would like to hold the requirements workshops in the company’s new garden courtyard. A risk may be that it might rain during those sessions.
  2. For each one of those uncertain events (risks), determine what the likelihood is that each one will materialize and then the impact of that. In Seattle, WA, raining on outdoor events is a higher priority than it is in Phoenix, AZ.
  3. Determine what will trigger the realization of the risk (how you know that it’s happening), and how you will respond when it occurs. This is your risk response. For instance, if the rain starts, that will trigger your risk response. You then know exactly how your team is going to respond because you have thought it out ahead of time.

Remember, BAs should perform risk analysis because not everything will go as planned. By developing appropriate responses, you are effectively planning for some of those situations that may not go as you expected. You will be able to keep the project moving in order to accomplish your objectives and not stumble or stall because the team doesn’t know what to do.

So what did Armstrong do when Ullrich attacked? Armstrong accelerated right along with him. He knew the risk that Ullrich posed, but instead of thinking about his response, it was calculated and thought out that morning with the team director. But don’t worry about Armstrong coming into your company and taking over your job as a BA just yet – he’s training for this year’s TdF showdown with Alberto Contador.

Don’t forget to leave your comments below

Paul Mulvey, CBAP, is a Lead Business Systems Analyst at UPS. He currently rides a Merlin road bike and runs a 53/39 up front and an 11-21 in the back, although with that ratio, the climbs seem to get harder each year. He can be reached at [email protected].

Breaking Down the Silos for Better Requirements Elicitation

BreakingDownTheSilos3I’m sure that by now we have all seen statistics about the reason that X% of projects fail is due to requirements. They always point back to the fact that the BAs did not capture the correct requirements. Well, maybe, just maybe, it isn’t our fault. It may be the way in which our companies are set up that force us to miss requirements. Yes, I said it; the way in which our companies are set up may cause us to miss requirements. But now that it has been said, we can no longer use it as an excuse. We need to understand how our companies are set up so that we can overcome those obstacles and become more effective. If we work within product silos, we need to understand how to overcome these silos in order to develop an effective business process. First, we need to travel back in time to understand the foundational architectural principles.

A History Lesson

In order to understand the silos concept, let’s start by going back to Greece. The ancient Greeks, when not competing in the Olympics or writing epic poems about Odysseus, built temples. Imagine yourself as a temple worker assigned to column duty, we’ll call it column A. It was your job to understand the dimensions of Column A, what the column should look like, height and width, etc. Basically, you were a BA working within Column A and Column A only. Occasionally, you would interact with those working on Column B or C over lunch or something, and you would learn what they were doing. But, basically, you stayed within the confines of your own column and you made a great column. But there were business analysts back then that were assigned the responsibility of the Architrave. In architecture, the Architrave is the ornamental band that rests on top of the columns (sometimes called a lintel). If the BA working on the architrave did not coordinate all the efforts of the individual column makers, it would not work properly, or rest properly across the columns.

1.Greek temple façade showing “silos”

Many companies today are organized in very much the same way, but replacing the physical columns with product silos. We have built our product lines into neat, organizational silos (the columns from the temple), and the analysis work is performed within these silos. Since authority and control from the top of the column only extends to the bottom of the silo, analysis does not normally occur outside of the column, or silo. What happens is that when the Architrave project comes along, no one silo wants to take ownership of the work required to analyze it because it is not in their “column authority.” The result is that the business process that crosses over the silos is not fully analyzed because no one examined something that went across the silos. A manager in silo A controls the activities (and probably budget) within the silo and is reluctant to allow one of his analysts to go outside of the silo. The reluctance may come from budget concerns (“If I’m paying for the analyst, I’m accountable budgetary-wise for the work that analyst performs”), it may come from control (“This is my department and my analysts only work on my projects”), or it may come from organizational policies (“No analysts may perform work outside of their department”). However it occurs, it hurts the project because the overall business process that needed to be analyzed was not analyzed.

Let’s create a hypothetical example of how this happens. Imagine a grocery store with product lines (or silos) of Marketing, Retail, Sales, and Distribution. A corporate sponsor comes up with a great idea to have customers order groceries over the internet. Since it was initially pitched as a Marketing idea, a Marketing BA performs a stakeholder analysis and determines that Marketing need to update the store’s website, and Distribution needs to deliver the product. So Marketing goes off and starts collecting their requirements, and Distribution does the same. But the Distribution BA uncovers that Marketing has no plan to sell the product, so Sales should be contacted for their input. Now Sales is involved, but they are off creating their sales requirements, and not involved with Distribution or the website. The head of Retail hears about this project, and wants his silo to be involved because there could be an option for customers to pick up their ordered groceries at the closest retail store and thus drive business to his retail sector. So now there are four separate efforts going on to create the requirements, but they are not talking to one another. When they all come together, the requirements do not match up, as each person understood the effort from a different perspective (e.g. they were all concentrating on their individual column). The end result is that it’s a mess, and there are probably cost overruns, unsatisfied sponsors, and the business loses a lot of potential sales if their competitors are able to beat them to this particular idea.

Look at the Business from the Architrave’s Perspective.

The Architrave has the advantage of sitting across all of the columns. To do so, it needs to have a lot of information about each column: it needs to know how much weight each column can hold (or manage), it needs to know the design of each column, to keep that design going into the architrave, and it needs to span across all the columns. It also has a viewpoint above the columns, so it is able to see the “big picture.” Before you can even go into understanding the business process, you need to determine exactly what business processes that you are going to discuss. Since you are at the top, think of processes that you would have to perform as part of this Web-ordering idea. There are probably more, but within 10 seconds, you can probably come up with, “Sell new service”, “Promote new service”, “Order product”, “Purchase product”, “Distribute product” and so on. Look at all of these from a process-perspective, not a “which silo owns it?’ perspective.

Figure 2. Business processes represented across business silos

By looking at it from a business process level, we can see that the process goes across silos for several of these processes, and we begin to see how they work across the entire organization, not just in one silo. For instance, with “Promote new service,” we might just think that it is a Marketing function, or a Sales function. But when the analysis is done across silos, we are able to understand that the real intent of the sponsor is to combine the promotion with the Retail function so that they can coordinate the promotion. If analysts did not study the business process from a point-of-view of the business process, the coordination with the Retail channel would have been lost. Also, it may be that in studying the promotion process, the analysts discover more groups that become stakeholders: Legal, to negotiate contracts for Radio and TV ad spots; or the Customer Call Center, to understand the new service and be able to explain it to customers when they phone with questions. You will likely find more stakeholders as you analyze the entire process, instead of just looking at it from your own silo’s perspective.

Completing the Temple

Alas, while it’s great to perform the process analysis at the Architrave level, one needs to have the support of the columns in order to hold it up. A process cannot survive on its own without the foundational support of the silos. Eventually, the weight of the Architrave has to be supported by the columns. This is where the business process falls into the silos. After developing the business process, then you can start developing solutions to support the business process. By looking at the process as a whole, and from above all the silos, it becomes easier to determine exactly what needs to occur to support the process, and to assign the functionally to each silo as necessary. Also, since the entire process is documented, analysts do not get caught in the trap of having each silo assume that another one is going to complete work X or work Y. Black boxes may still be around, but going into the solution, the silos know which one is tasked with supporting that piece of the process.

Hopefully, you have a better understanding about the necessity to understand how the business operates throughout the business, not just in a single silo. Not only will you have a better documented business process, more well-defined stakeholders, but you will also experience better coordination across the silos when it comes time to develop the solution. I would like to explain more about Greek culture and mythology, but I have to run, I’m lashed to the mast of my ship, and I hear the sirens calling me…

Don’t forget to leave your comments below

Paul Mulvey is a Lead Business Systems Analyst at UPS. He grew up with a Humanities professor father who would probably be very proud to know that his son has still retained knowledge of the Greek civilization. He can be reached at [email protected]

© 2010 Paul Mulvey

Disassembling Your Cube

Most of us in Information Technology have seen the movie OfficeSpace. It’s funny because we can relate to the situations that the main character, Peter, faced. I’m sure that many of us have experienced a “Did you get the memo?” situation but I question how many of us business analysts have disassembled our cube wall? In one scene, Peter disassembles his cube wall to connect with the outside world, and I’m suggesting that as BAs, we do the same thing. Now before you all take out your cordless drills and start physically disassembling your cubes, I’m speaking metaphorically. We need to break down the walls around us and understand the business that is looking for solutions.

Break Down the Wall

Many of us who practice business analysis sit within and report up through the IT environment. We may even have a title indicative of that such as Business Systems Analyst. But just because we are in IT, we need to stop constraining ourselves with IT thinking and understand what it is that our business does and how their processes work. In this age of telecommuting, multi-tasking, conference calls, and webinars, when was the last time that you actually sat with a business person as they performed their job to truly understand what it was that they did, and why they did it that way? Get out of that cube, get into the business, and learn what your business does. Better yet – see if you can learn how to do it and you try and do the work. This may be more challenging than you think; we often think that someone else’s job is simpler than our own. For instance, you may be studying an easier way for a business user to produce a certain report. When you perform the steps that they tell you, you might get completely frustrated switching between three to four different computer systems, writing down information from one to enter into another, etc. By doing so, you experience the same frustrations that they do, and you will quickly start to think of a better way to do it. While not everyone can perform the work that they are analyzing (say, a BA designing flight controls systems for a military jet doesn’t get to fly the jet – but boy, wouldn’t that be fun!), if you are able to do the work it gives you great insight to the troubles that operators face daily. You start to see the world outside your cube, looking in at IT.

Looking at your profession from the outside is not easy. Be prepared to see things that you do not like, such as disjointed ways for users to interact with the software that your organization puts out. One example; most of us probably use Microsoft Office. This office suite of tools tries to standardize commands as much as possible between Word, Excel, and Powerpoint. Pressing CTRL+F in Word (or COMMAND+F for us Mac users) initiates a search, same as the other Office products. Now consider all the other applications that you use. Is CTRL+F the same in all? I can name a text editor that uses F3 as the search, another program that has no hot key for a search and in which I have to click a button. And that’s just off the top of my head. Does your organization roll-out different applications from different product portfolios that have the design of Office’s parallel commands? Do your accounting applications search in the same way that MS Office does? How about your other applications? By getting outside of your cube and looking in from the outside, you will increase your familiarity with the area that you support. The end result is that you will be able to see a lot more of the world by getting out into it than just looking at it from within your cube.

Don’t Just Accept the Solution

By getting into the outside world, you start to see how the business operates and can start seeing solutions that you didn’t previously know existed. Users may not tell you everything because they are smart and figure out ways to get things done either inside or outside the system (or problem area). What they may see within their span of control as a solution may be completely valid. Based on everything they know, they are requesting a change in the process, but what they are really doing is proposing a solution. It’s your job to get out into the business to uncover the problem instead of just accepting their solution.

Consider this; you, as a BA, have a request from the business to create an Excel-based report from Application A. In your cube, you do your job as a BA and ask what the business need is for this new style of the report. The answer is that the business needs to input this report into an Excel spreadsheet and they cannot do this with the current MS Word-based report. Requirement captured, right? Almost! If you had been outside your cube and in the business, you would have seen users outputting the Word report from Application A and manually entering the data from the report into an Excel spreadsheet in Application B. If your requirement was to create the Excel report, it would have made the key-entry situation easier, but you still have a manual process in place (export from one system and input to another). By getting out of your cube and into the business, you would have seen that the real problem was that the business’s process required getting data from Application A to Application B, and it was not the report format. Merely accepting the requirement at face value may have saved the business a little time, but in the long run, understanding the business problem by seeing it in action would have resulted in saving a lot more time, and would have been a better solution.

Partner with the Business

Because we are so comfortable in our cubes, we tend to stay there. Yeah, we do have nice chairs but we can’t sit in them all the time. We have to get out into the business areas that we support and get them to trust us. Trust us to the point that they know that we really are there to help; to help uncover ways to improve their processes, and to help make their lives easier.

If you can show the business people that you are not just there to “take their order” as I’m fond of saying (like a waiter/waitress at a restaurant), they will become your trusted partner. But, you have to show them that you can bring something to the table. To do this will require that you understand their problems and bring a solution that shows you understand. If all you do is write down what they request, you provide no additional value. They received what they asked for, and they will wonder why you are even involved in the process in the first place.

Consider the difference from their viewpoint; they may be asking for that new report, but you find a better way to fix their business problem and make their jobs more efficient. Now they will see you as the change agent and the person who understands the problems that they face. They will start to contact you instead of their normal channels because they have seen that you were the one who sought to understand their problem and that you solved it. Instead of just the solution that you delivered on the first project, they may well start to contact you and suggest other fixes that you could make. The business has seen that you, as the BA, are the one that solved the problem on the original project, so now you are a trusted partner. While not all of the changes that they suggest will be something that you can make (or even have the budget for), they are problem areas that the business experiences day in and day out. They can be logged as future projects, or if in an agile development world, onto the project backlog.

So go ahead and break down those walls around you, and not by disassembling your cube. And while I welcome e-mails, I don’t want to see any in my inbox from your management saying that I told you to take apart your cubes. Remember, I was speaking metaphorically.

Don’t forget to leave your comments below

Paul Mulvey is a Lead Business Systems Analyst at UPS. He has just completed creation of a BA Certification program within UPS and is sitting for the CBAP exam in March. He can be reached at [email protected].