Tag: Risk

From the Archives: Diving Into Unofficial Roles & Responsibilities of the Business Analyst

Written by Angela Wick on August 18, 2016. Posted in Articles.

Why are we the psychologists and the babysitters?

Often on airplanes I get asked, “So, what do you do?”

I am sure if you travel you get this one as well! Do any of you answer with “I am a therapist?”

Well, I do, and it works really well! I am a therapist that helps business teams and technology teams work together and create meaningful products, services, and systems.

I help them agree on changes and create a shared understanding.
I create a process and platform to communicate.
I make them both feel like they are the ones who came up with the ideas.
I make conflict seem like a non-issue and create win/wins.
I present options and alternatives and work through, with the pros and cons.
And, they pay me an hourly rate to do this!

You rarely see “therapist” on a list of required BA skills, but a comparison of BA job descriptions across industries, across nations or even across a single organization, yields an amazing variety of responsibilities and required skill sets. Even the industry leading IIBA BABOK (embedded link: http://www.iiba.org/babok-guide.aspx) highlights more than 20 underlying competencies that support the professional practice of business analysis.

Related Article: Your Next Business Analyst Will be a Robot

Lengthy BA skill lists that include creative thinking, technical skills, adaptability, listening, solution knowledge, teaching, testing, leadership, facilitation, etc., confirm our reality that BAs are expected to be the Swiss Army Knife of the project, product, IT, or operations world. It’s no wonder that most BAs claim to “wear many different hats.”

Despite the wide variety of accepted roles and responsibilities, BAs are often asked to wear strange hats—to take on unofficial duties that don’t really fit the wide range of normal. I get asked in my classes on a regular basis: “Is it the BA’s role to ___________?” Students fill in the blank with common things like testing, coding, and project management, but hostage negotiator, spy and therapist have also landed at the end of their question!

Here are a few true stories I’ve collected over the years, with names changed to protect those who might be embarrassed by their big, floppy, gaudy, leopard-print hats:

Undercover Agent

BA Becky was a well-respected senior BA in her organization. The BACoE leader recognized her accomplishments by asking her to mentor a struggling team. The odd part of the assignment—BA Becky was asked to be an undercover mentor—she was not allowed to tell the team she was mentoring them.
BA Barry was on a project team that needed to create a pricing strategy for the organization’s products. The strategy included several assumptions about their competitor’s pricing. The team leader asked BA Barry to “secret shop” the competitor to validate the assumptions.

Ghost Writer

BA Beth asked her stakeholders from California, Texas and Arizona to travel to Minnesota for a full-day face-to-face requirements review meeting. The day before the big meeting, the project manager realized that BA Beth’s requirements were a huge mess. The requirements review would be a disaster. So, the PM asked BA Bart to stay late, re-do BA Beth’s requirements, and bring the new and improved requirements document into BA Beth’s meeting.

Translator

BA Brody was fluent in Spanish, so it makes sense that he was asked to review, translate, and validate a 6-months old, 300-page requirements document written in—Portuguese! The business sponsor asked, “Since you are fluent in Spanish it won’t be too hard to translate, right?”

Scapegoat/Peace Negotiator/Psychologist

A crafty project manager tossed BA Ben under the bus when she asked Ben to present a feasibility analysis to an erratic, f-bomb-wielding business owner. The business owner had great vision, but cost and feasibility did not meet his expectations, and the PM did not want to be in the line of fire.
BA Belinda got along well with everyone on her project team. So, naturally, the project manager asked BA Belinda to “figure out” a way to get a notoriously mean and stubborn database engineer to cooperate with the team.
Late one afternoon in mid-October, BA Betty found out she would be laid off at the end of the month. That same day, BA Bill was asked build a relationship with Betty to get the information he needed to take over Betty’s requirements work for a few projects. Obviously, laid-off BA Betty was NOT excited to do the knowledge transfer!

Babysitter

BA Brent was very smart but quite odd. His analysis work was solid, but his social skills were suspect. The team leader asked BA Betsy to help Brent stay focused, to monitor his interactions with the business SMEs and to step in when needed to ensure deadlines were met.

After Hours Snooper

BA Bill worked in a business unit where employees processed checks. Employees were required to secure the checks when they left the office each night. To validate compliance with check procedures, BA Bill was asked to stay late one night to search employee cubicles for unsecured checks.
Important documents were missing from several client files in BA Brenda’s organization. Brenda’s team leader asked her to return to the office after hours and search processing analysts’ desks for the missing documents.

Data Detective

A third-party software vendor refused to provide their data model to their customer. The customer needed the data model to develop requirements and meet the needs of their business. BA Barb, a member of the customer project team, was asked to reverse engineer the vendor data model.

What is it about the BA role that makes us prime targets for these odd assignments? I don’t see project managers or testers or developers wearing these odd hats.

The majority of these unofficial roles rely on our ability to build and maintain relationships with a wide variety of people. Maybe, these odd assignments are a compliment? Perhaps people skills are the primary strength of effective BAs, and these unofficial roles are just a side-effect of our success.

Have you ever taken on one of these odd roles or do you have another unofficial BA role to add to my list? Share your story in the comments below!

Note: This article was originally published on batimes.com on September 14, 2015

Well, I do, and it works really well! I am a therapist that helps business teams and technology teams work together and create meaningful products, services, and systems.

· I help them agree on changes and create a shared understanding.

· I create a process and platform to communicate.

· I make them both feel like they are the ones who came up with the ideas.

· I make conflict seem like a non-issue and create win/wins.

· I present options and alternatives and work through, with the pros and cons.

· And, they pay me an hourly rate to do this!

Here are a few true stories I’ve collected over the years, with names changed to protect those who might be embarrassed by their big, floppy, gaudy, leopard-print hats:

Undercover Agent

· BA Becky was a well-respected senior BA in her organization. The BACoE leader recognized her accomplishments by asking her to mentor a struggling team. The odd part of the assignment—BA Becky was asked to be an undercover mentor—she was not allowed to tell the team she was mentoring them.

· BA Barry was on a project team that needed to create a pricing strategy for the organization’s products. The strategy included several assumptions about their competitor’s pricing. The team leader asked BA Barry to “secret shop” the competitor to validate the assumptions.

Ghost Writer

· BA Beth asked her stakeholders from California, Texas and Arizona to travel to Minnesota for a full-day face-to-face requirements review meeting. The day before the big meeting, the project manager realized that BA Beth’s requirements were a huge mess. The requirements review would be a disaster. So, the PM asked BA Bart to stay late, re-do BA Beth’s requirements, and bring the new and improved requirements document into BA Beth’s meeting.

Translator

· BA Brody was fluent in Spanish, so it makes sense that he was asked to review, translate, and validate a 6-months old, 300-page requirements document written in—Portuguese! The business sponsor asked, “Since you are fluent in Spanish it won’t be too hard to translate, right?”

Scapegoat/Peace Negotiator/Psychologist

· A crafty project manager tossed BA Ben under the bus when she asked Ben to present a feasibility analysis to an erratic, f-bomb-wielding business owner. The business owner had great vision, but cost and feasibility did not meet his expectations, and the PM did not want to be in the line of fire.

· BA Belinda got along well with everyone on her project team. So, naturally, the project manager asked BA Belinda to “figure out” a way to get a notoriously mean and stubborn database engineer to cooperate with the team.

· Late one afternoon in mid-October, BA Betty found out she would be laid off at the end of the month. That same day, BA Bill was asked build a relationship with Betty to get the information he needed to take over Betty’s requirements work for a few projects. Obviously, laid-off BA Betty was NOT excited to do the knowledge transfer!

Babysitter

· BA Brent was very smart but quite odd. His analysis work was solid, but his social skills were suspect. The team leader asked BA Betsy to help Brent stay focused, to monitor his interactions with the business SMEs and to step in when needed to ensure deadlines were met.

After Hours Snooper

· BA Bill worked in a business unit where employees processed checks. Employees were required to secure the checks when they left the office each night. To validate compliance with check procedures, BA Bill was asked to stay late one night to search employee cubicles for unsecured checks.

· Important documents were missing from several client files in BA Brenda’s organization. Brenda’s team leader asked her to return to the office after hours and search processing analysts’ desks for the missing documents.

Data Detective

· A third-party software vendor refused to provide their data model to their customer. The customer needed the data model to develop requirements and meet the needs of their business. BA Barb, a member of the customer project team, was asked to reverse engineer the vendor data model.

What is it about the BA role that makes us prime targets for these odd assignments? I don’t see project managers or testers or developers wearing these odd hats.

Have you ever taken on one of these odd roles or do you have another unofficial BA role to add to my list? Share your story in the comments below!

5 Things Your Project Customer Assumes You Know

Written by Brad Egeland on February 15, 2016. Posted in Articles. 4 Comments on 5 Things Your Project Customer Assumes You Know

The Business Analyst and Project Manager should be focused on the success of the engagements they are leading. The Business Analyst is leading a team of skilled resources who should have one common goal in mind – to roll out a successful solution to the project client.

Do we know everything? No. Do we know everything about the project we are leading and about what we are supposed to be doing? We should! We aspire to, but there are likely a few things missing along the way. We learn as we go along. Do we know what our customer is always thinking? What they think about our performance or how we are managing them, the team and ourselves? No.

Well, I’m hopefully going to close that knowledge gap a little.

Here are my top five things that your project customer assumes, hopes or wishes you knew about them and the project you are leading for them.

You’re the expert, not them.

You are the skilled Business Analyst or consultant. You and the Project Manager are the individuals leading the team with the skill set needed to identify, design, and develop their solution. If they had that skill set or the time to do it, they wouldn’t need you.

{module ad 300×100 Large mobile}

Understand that you are the expert. The client knows that and wants you in that role. They may annoy you, demand things, they may even seem like they are getting in your way or trying to take over, but really, at the end of the day, they will be the most satisfied and confident if you are in control, take the lead, and direct them.

Money is very important to them.

We all must answer to someone higher up with respect to budget, profit margin, and overall financial health of the work we are performing. It works the same way for the project sponsor.

The project customer cares about the money they are spending on the project, and they want to feel comfortable that you are spending it wisely. Therefore, they expect this to be reflected in any weekly status reporting and dashboard view in terms of actions, work progress, and often budget analysis.

They have a day job.

They want you to know that while the project is very important to them and may be an important part of their career, they also have a day job. Rarely is the project you are working on their only responsibility. After all, they shouldn’t have to do too much on the project because you and your team are the real experts, not them, right?

They have other tasks to perform, bosses to report to, and even teams to lead. So they might not always be available with the information or decisions you need.

Keep them engaged, give them time, and be patient. And take charge and make good decisions in their absence.

They do not know how to test very well.

Your client may not like to say it, and they may not show it, but it is often the case that project customers do not know how to test very well. And they certainly won’t be experienced on this new solution you are planning to implement. Help them. Don’t do it for them – that would be a conflict of interest. But you can help them with test cases and test scenarios and hold their hand through the user acceptance testing (UAT) process.

You may find yourself and some individuals on your team spending more hours before and during UAT than you had in estimated in the budget, but it’s worth it, and you’ll know to include more hours in the schedule and estimate next time.

You are not their friend.

Keep it professional, no matter how friendly or easy the communication becomes. If you let it go too casual, you risk missing some information sharing along the way by assuming the other party may already know.

The customer may seem very comfortable with you, but you are still not their friend. They are paying for your services. Run professional meetings, continue professional conversation, and engage them like they are the project sponsor, not your friend from high school. And avoid the drinks at the bar with them after a big onsite meeting – it’s just not professional.

Summary / call for input

We do everything we can for our project customers. Lead their projects, manage the budget, engage them and try to keep them as focused and confident as possible throughout the project. But we can’t get inside their head, and they don’t tell us everything. If we could, though, these are things that I feel they would be thinking that we should know as far as what is driving their behavior and management of the process.

Remember, the Business Analysts, Project Managers and teams are the professionals hired to manage the projects. But in the end, it is the customer’s project, so keep them engaged and informed throughout. Have those periodic one-on-ones with the project sponsor to ensure that you know what they are expecting of you on each engagement and at every turn. Sometimes their expectations need to be reset, and that’s ok.

The key is never to stay out of touch with them for very long.

What about our readers? What do you think your project customers assume you know about them and the projects you plan and manage for them? What do you think they wish you realized as far as what’s important to them? What, from your experience in working with project customers and key stakeholders, would you add to this list or change about it? Please share and discuss.

In Security

Written by Steve Blais on February 2, 2016. Posted in Articles.

Let’s face it. It’s all about information. Everything we do is about information. We need information to do our job, and our job is usually about information, information that is collected from a wide range of sources over a long period of time, information that is created through the combination of other information, information that is printed, displayed, organized, manipulated, and stored for decades if not eons.

And that information is important. We depend on information. We use information to know what is going on, to make decisions, to entertain us, to communicate, or simply to take us to places we’ve never been. It’s all about information.

It’s all about information security

And then, it’s all about security of that information; who can see it, when they can see it, how much of it they can see, and in what form will the information be kept and for how long? Should the information we need be secure and to what level? Should it be private, and private to whom? When should it be released? How long should it be kept before releasing or destroying? Can it be destroyed?

Security. Even in IT, we tend to view security as a specialist’s area. Security people are strange birds, and security “stuff” is generally the bailiwick of specialists who think differently than the rest of us. They have their own vocabulary – black hat, white hat, encryption, public and private keys, breach, vulnerability, hacker, cracker, malware, and so forth. As Business Analysts, and even as Developers, information security is viewed many times as a layer of nonfunctional requirements and / or software added to the basic business requirements at some later date in the software development lifecycle. And in many cases that is the way it has to be.

But consider this; a breach in security is bad for business. Loss of information is not simply an IT issue; it is a business issue. The loss of information might well lead to the loss of the entire business. Security requirements are business requirements. Consider even further – the level of security is based on the value of the business assets being secured. Therefore, it is necessary to analyze the business assets to determine the value of those assets and what levels of security are necessary. Note the words “analyze the business”; in other words, business analysis.

We are all insecure

The reality in information security is that there is no foolproof way of securing the business’ information except by physically disconnecting all the information from any external access. In other words, “unplugging”. And while that was a perfectly valid business strategy 50 years ago when I started, today the concept of being completely disconnected from the Internet and still being successful in business would be considered far-fetched. (Actually for most businesses back then “unplugging” was not an option since there was nothing to “plug” into. Locked file cabinets containing the business “secrets” sufficed.) In those days, we who defined requirements, design systems, wrote the code, and tested the results were not worried about information security. Security, not just information security but all security (there was no category called information security at the time) was indeed handled by a completely different organization with whom we in data processing (as it was called back then) rarely had interactions. Security back then was focused on physical security, preventing unauthorized access to the premises, and to those locked file cabinets.

A Security Guideline for Business Analysts

Since we cannot, as Business Analysts, developers, or even security specialists, completely prevent an intrusion or a breach from occurring in today’s interconnected spider web of information, we need to have a guideline, a balance between security and convenience, between preventing access by the bad guys and inappropriately filtering out the good guys. If we do business on the Internet, we need to make it as easy as possible for those seeking to do business with us to access the information they need to do business while at the same time preventing those with malicious intent from accessing, manipulating, or modifying our information.

So we have this guideline that was written on a card which I kept pin on the wall of my office in a previous life in security:

Make the cost of the breach exceed the value of what is compromised.

If we are able to implement this guideline effectively we should be able to present the majority of damaging breaches, and pretty much all intrusions based on economic gain. What this does not prevent against those who are attempting to break security for reasons of revenge, “fun”, or simple malevolence. And those areas are indeed the purview of the security specialists, and probably also the psychologists.

However, the general approach will be effective. Considering that the “cost” includes not only the time, effort, and or monetary expenditures to get to the information, but also the length of time of exposure. For example, the “Club” which many car owners have affixed to their steering wheel to “prevent” theft of their vehicles does not actually prevent theft. Cars can be stolen with a Club on the steering wheel. What the Club does is increase the amount of time the car thief has to spend to steal the car; thus, the “cost” of the theft is in the extended exposure and increased potentiality of being caught. If the vehicle is a Ferrari or some other car that costs six figures to purchase, it might be worth the risk. If the vehicle is my 17-year-old sedan, it clearly would not be. So the “cost” can also be measured in “exposure time” for the bad guy.

To make that guideline work effectively, the business must first have a definition or assessment of the value of its information. Not all information has the same value. And the cost of securing that information should be directly proportional to the value the information has. In other words the organization should spend more time and money securing their customer master files which have national identification numbers and credit card information than in securing the departmental picnic list file that contains the names of employees attending the annual picnic and what dish they are bringing (to prevent too many bags of potato chips and not enough vegetables).

{module ad 300×100 Large mobile}

The Business Analyst’s Role in Security

It takes business analysis to determine and assess the value of the information in the organization for any given business process or information system. Since security should not be an afterthought to be added after the systems or changes have been developed, it is up to the Business Analyst to determine the value of the information, all the information, being used by a particular business process or information system. The Business Analyst may not be required to identify threats and or countermeasures which is indeed the domain of the security professional (although I have seen many Business Analysts involved with threat assessment in organizations because of their breadth of knowledge of the business activities, processes, and information.)

The Business Analyst also provides a valuable check and balance to security by identifying when security measures may be too much – they prevent business from happening or make it exceedingly difficult – thus impairing the organization’s mission or keep it from achieving its strategic goals.

Helping the organization become secure

We typically think of security in terms of protecting against malicious intrusion or identity theft. But when we consider the entire business there are many other areas in which security is important to the business. For example, corporate espionage is a threat to many businesses. Privacy of both the employees using the systems and customers entering their data into the corporate databases has been increasing in importance the century and generally falls under security. While security is a policy of the organization to protect the organization, privacy falls under regulations of countries and other jurisdictions and may cause an organization to run afoul of the law.

Many times the solution to a security problem is not additional software or technological engineering, but a simple change in the business process. The Business Analyst is the primary role familiar with the entire business process and is able to identify security weaknesses in the human activities which in many cases is where a security breach starts.

While the technologists will focus on the networks, the portals, the access points, the web servers and other technology-based vulnerabilities in the organization, the Business Analyst can look at a wider picture that includes the movement of information outside the computers throughout the company and the people who handle that information.

It takes a Business Analyst to put a security problem into a business context. It takes a Business Analyst to evaluate whether the assets being protected are worth the cost of the protection. It takes a Business Analyst to understand the human factors involved with security issues and security breaches.

The Business Analyst can provide valuable information to the security professionals to help make their job easier and more accurate thus adding value to the organization (in terms of increased and better security, and a better cost-benefit ratio for the security activities) which is what the Business Analyst is all about.

Let’s Make a Deal – The Art of Project Negotiation

Written by Brad Egeland on January 11, 2016. Posted in Articles. 1 Comment on Let’s Make a Deal – The Art of Project Negotiation

You’re a Business Analyst or Project Manager on a technical project. You probably realize most of the roles and hats you need to play and wear. You are a task master, a resource manager, a change agent, a master communicator, a meeting facilitator, a financial wizard, and a critical decision-maker.

And now you find out you are also a master negotiator. Yes, master negotiator. Or at least, you should be. At least, you better be ready to at least “fake it till you make it.” You may be negotiating right now on your projects and not really realizing it, but you might want to focus on where you are doing the negotiating and pinpoint what you are doing and work at improving those skills. Why? Because you will always need those negotiating skills – likely on every project that you manage to some degree – and you’ll want to continually improve in this area. Again why? Because you often need to rely on winning those rounds of negotiation in order to win on your project or keep it moving forward and keep your project customer satisfied and confident in your ability to keep the project running efficiently and on track in terms of time and budget.

Do you consider yourself a negotiator?

Whether you are a Business Analyst or Project Manager, you are negotiating from time to time on the projects that you are engaged on or managing. Do you consider yourself a negotiator? Have you been aware of these events as the projects unfold? Let’s consider what these negotiating opportunities and needs are so that we can be aware of them the next time they occur and use our negotiation skills to our maximum benefit and become even better at negotiating when we need that skill next time. Some negotiation events or opportunities we likely run into during the course of some of our projects throughout our careers are:

Negotiating for resources. Maybe you really need a top technical resource, and you can afford to put more of a part-time Project Manager or Business Analyst on the project – or one with a little less experience – because it’s a very short-term, but very complex project with a complex technical solution. You negotiate that resource acquisition to the most favorable way possible for your project, right? You look at the landscape of your resource needs and trade-off accordingly because you’re never going to get the best of the best at every project team member position anyway.

Negotiating for task assignments. You look at your resources on the project team and the tasks to which you need to assign them. When are they going to be available considering their other project commitments with other Project Managers and Business Analysts and which tasks do they love or hate. Some “don’t do windows”, so to speak. I had a contractor on my house who would do everything but hated to paint, so I found someone else to paint and he gave me a great price on all the work he loved to do. Negotiation – it gets tasks assigned and to the right people who have the right skills and love that specific work.

Negotiating for deadline dates. Sometimes deadline dates need to move, for whatever reason. Usually for the good of the project, but that doesn’t mean you won’t need to do a little negotiating with the project client to make date changes happen. As the Business Analyst, you can work with the technical team and see what functionality can be shifted around if you are doing a phased rollout on an Agile project. The key is to show the client documentation that convinces them the project won’t be at risk, and the trade-off is not going to affect them adversely. It may take some skilled negotiating, and you will have to do this from time to time. If you haven’t yet, you will.

Negotiating for project funding. When have you ever run a project that had an abundance of funding available? If additional funds are needed – if that is even an option – you may find yourself negotiating for those extra funds. Whether that’s from your senior management or the BA going to the client and explaining why the technical solution is going to cost more than originally planned – either way negotiating skills will likely come into play.

Negotiating on project change orders. Just as for additional funding, you may find yourself negotiating with the client to get needed change orders approved. Usually, this will come up as needing to give away some work for free in order to get sign-off on a needed change order that will add needed functionality to the project but also will end up costing the project client more than they originally planned to spend.

Negotiating on technology used for project solutions. Sometimes the client comes in with a technical solution in mind. In fact, the latest and greatest technology may be the entire reason the project was initiated. How that technical solution is implemented, and even the technology behind the solution may need to be changed from what the sponsor originally wanted for practical purposes or to stay withing budget and time constraints. Either way, negotiations will likely need to take place.

Summary / call for input

I realize that some of these instances just happen, and you may not have considered them negotiating points. But many times they are. And you can leverage one incident against another when necessary to get what you may really need or want on the project. You can take a less experienced tech lead resource in exchange for the top data integration specialist this time around because data integration is critical on this project but you can let the top tech lead go to another project. In the long run, you’ll be ok. There, you just negotiated. It’s often give and take – you gave, and then you took.

What about our readers? When have you had negotiating opportunities on the projects you are working on? What strategies do you employ to get the things you need and the dates you require and the funding that is critical to your project? What other negotiating opportunities would you add to my list above?

Leadership Lessons: A 7 Phase Methodology – Phase 2 – Establish Rapport

Written by Peter de Jager on October 27, 2015. Posted in Articles.

Editor’s note: We will be showcasing each phase of Peter de Jager’s methodology in weekly posts. Click here for phase 1 and check back every week to read the next phase.

As someone involved with ‘selling’ the change, remember the lesson from sales. People buy from people they like. Do they trust you? Change management is an exercise in diplomacy.

Don’t have all the answers.

Change ‘agents’ have a tendency to outline the entire change. They see the change as something they ‘own’ and must, therefore, dictate the exact ‘solution’. A system written with the users input will ALWAYS have a better chance of success than a solution foisted upon them by an isolated IS. The role of a ‘change agent’ is to make change possible, not to define the change to be adopted.

Support empowerment

Empowerment means giving the target audience the option to make decisions. The flip side is that you, the change agent, must give up the desire to make all the decisions. The more you leave in the hands of the target audience, the more you build their sense of ownership.

Don’t ask for ‘buy in’

When you ask for ‘buy in’ you’ve already failed. It means you’re presenting them with both a need to change and the ‘solution.’ To be more precise, you are presenting them with your solution. You’ve invalidated any empowerment you may have created.

Seek out their ‘vision’

Again, this meets their need for ownership in the change. We resist change most when it leaves us powerless when we have no control over our future.

Identify influence leaders, early adapters, and resistors

Influence leaders are those whom others look to for guidance; they are not necessarily those early adapters that take to a new change first. Your time is best spent getting influencers to change, rather than catering to the early adapters or resistors. (Of course, sometimes you’ll be in a situation where the biggest resistor is also the biggest influencer.)

Change thinking: ‘Change Agent’ vs. ‘Inflictor of Change’

The term ‘change agent’ creates an image of a person on a mission. Another phrase more in keeping with the reality that change hurts is ‘change inflictor.’ It forces you to keep in mind your primary task is to disrupt the status quo. When you think like a ‘pain inflictor’ then you have one strong objective – reduce the pain. Consider your local dentist. His single goal is to minimize the pain experienced during a specific ‘change’. By showing concern for people’s reluctance to leave their status quo behind, you also reduce their resistance to the proposed change.