Tag: Planning

Why Cyber And Physical Security Needs To Be Top Of Mind For Business Analysts

Written by Thomas Wright on June 2, 2022. Posted in Articles.

Cybercrime costs organizations $2.9 million every minute and costs major businesses $25 per minute due to data breaches.

It is no secret that cybersecurity is a top priority for all businesses, especially those adopting emerging cloud based and IoT technologies.

Cyber and physical security are becoming increasingly linked concepts, and business analysts must be prepared to include physical and digital security in any project they oversee. Keep reading to understand how you can implement a physical and digital converged security strategy in your business.

Why Business Analysts Should Have Cybersecurity Knowledge

Cybersecurity is part of risk management and should be included in every project your company oversees.

Since cloud-based technologies are included more in physical security strategies and are necessary to support hybrid working strategies, business analysts need to understand cybersecurity better.

The business analyst is the technical liaison between the project manager and the technical lead. The business analyst must be able to straddle both worlds of project management and the technical side of the operation.

By ensuring a thorough knowledge of cyber and physical security, the business analyst can improve communications and create swifter operating procedures. Business analysis isn’t just common sense and requires knowledge of key aspects within a business’ infrastructure.

Merging cyber and physical security is necessary to meet modern security demands, as the internet of things (IoT) and cloud-based technologies are making businesses more exposed to hacking. The data analysts need to evaluate is hosted on cloud-based platforms that require protection to prevent a breach.

How To Implement Better Cybersecurity Practices

Here are some of the best tips for business analysts to modernize their security strategy to handle physical and digital security threats. Better cybersecurity means more trust from stakeholders and protection from potential losses caused by the exposure of sensitive data.

Merging Physical And Digital Security

With the increased adoption of the internet of things (IoT) and cloud-based technologies, a restructuring is required within the facets of your business’ security staff. Housing digital and physical security teams separately can make modern security threats increasingly challenging to handle effectively.

With assets becoming both physical and digital, your physical security staff and IT team may have difficulty determining which security elements fall under their jurisdiction. By merging both teams, you can improve their communication and create a physical and digital security strategy that allows for faster response to physical and digital security threats.

You can integrate cybersecurity software with physical security technologies to prevent unauthorized users from accessing critical security data. You will modernize your cloud-based security system and make it impervious to physical and digital security breaches.

Using Physical Access Control To Protect Digital Assets

Your office building is home to many digital assets that store sensitive data. If an unauthorized user gains access to your physical servers, your data can be vulnerable. However, you can install door locks that prevent unauthorized users from entering your building by installing access control technology.

Mobile credentials can be used for access control security, which has many benefits. Users will be able to download an app and receive their mobile access key, rather than waiting for a physical key or keycard to be given to them. Bluetooth access readers can detect mobile devices stored in pockets and bags, meaning that your employees can enter the building without even removing their device and presenting it to the reader. Smart door locks can enhance your security and increase the convenience of your employees.

Using A Zero-Trust Security Strategy

A zero-trust security strategy does not assume the trustworthiness of employees and building visitors. Zero-trust can be applied to both physical and digital security strategies to remove the possibility of an internal security breach.

Access control door locks can be installed internally in your building to ensure that permissions to areas containing sensitive data and company assets are only granted to users that require access. The same principle can be applied to your cybersecurity strategy, only giving users permissions to access the data they need to perform daily operations.

A zero-trust security strategy is essential to eliminate the risk of an internal security breach that could cost your business money and lose your stakeholders’ trust.

Cybersecurity Training

Data is more vulnerable in a hybrid or remote work model, which means your employees should receive training on keeping their devices and networks protected. You can start by providing basic cybersecurity training covering the following topics:

How to avoid phishing scams.
How to set strong passwords.
How employees can keep their device software up to date to avoid vulnerabilities.

By providing your employees with basic cybersecurity training, you can significantly reduce the likelihood of a cybersecurity breach caused by human error.

Summary

Business analysts face new challenges when it comes to overseeing projects that are sufficiently protected in terms of both the physical and digital. A converged security strategy can combine physical and digital security strengths and help to futureproof your business against the changing nature of security threats.

Project Gateways: Land Or Abort?

Written by Adrian Reed on May 25, 2022. Posted in Articles.

A while back, I heard an airline pilot interviewed on the radio. There had been hurricane force winds, and the pilot was explaining how pilots deal with having to safely land aircraft in situations like this. One key decision is whether to continue to attempt the landing or whether to abort and ‘go around’ (attempt the landing again).

I was really intrigued to hear that pilots are taught to teach every approach as if it will end up being aborted. In fact, the pilot explained that they are taught that even in good conditions they should plan for an aborted landing as the default response, and this only changes once the relevant conditions for a safe landing are met. Even though aborting a landing is the exception, it is considered so important that they plan for it on every single approach.

Project Landing Strips

As a BA, it struck me that there is a parallel to be drawn with the project world. There is often an understandable and admirable optimism on projects, with a genuine desire to get the delivery ‘over the line’ in the required timescale and within the required budget. Yet history shows us that being ‘on time’ and ‘on budget’ alone are not enough… delivering a solution that doesn’t actually solve a problem or meet a need (or is not aligned with the organizational strategy) is unlikely to achieve the required benefits. With few or no benefits, what was the point in the first place? Spending good money after bad on a project that should have been canceled months ago is crazy, but it happens.

Now, I’m no PM, but I would expect that any good project method will require regular benefit reviews and there will be approval gateways where the project could (in theory) be stopped. Yet we have probably all experienced how this becomes harder and harder as time passes and as the budget gets spent. It would be a brave sponsor that aborts a project that has been in execution for a year and has spent millions of dollars. The ‘sunken cost’ fallacy comes into play here, along with the political ramifications of making a decision like this. Yet there may be times when it is the right thing to do… if the choice is to write off the existing spend or continue and commit another ten million dollars to deliver something nobody wants or needs, then surely the logical thing to do is to hit the ‘stop’ button?

This is perhaps where a subtle change could help. Project gateways and reviews are, in my experience at least, often progressed with the assumption that the project will continue unless it is proven that there is a major problem. As long as everything can be shown to be within agreed tolerances, it’ll pass through with flying colors. What if that perspective was changed so that the default is to stop—or at least pause—the project unless it could be established that the benefits will still be achieved? If the emphasis changed from “prove it won’t work” to “prove it will work”? If red lines or “key failure indicators” were defined up front and examined too?

Ironically, this was probably the original intent of project gateways. They ought to provide efficient, fast and robust scrutiny on project investments. However, I’m sure we’ve all worked in situations where they are seen as somewhat of a ‘tick in the box’ exercise. I remember hearing a colleague report that they’d found benefits being double-counted in a business case. They were shocked with the response “oh, don’t worry, we need to get this one through—we’ll leave it in as we can always find some benefits elsewhere if we need to”. I feel sure they will have escalated the matter, but this illustrates the types of challenges that practitioners face.

But Don’t Go Too Far!

There is one additional aspect that should be considered here. As Christina Lovelock argues in her excellent article “Practicing Practical Optimism”, there can be a tendency to place too much emphasis on risk. These things are always a balance, but just as the pilot plans for an aborted landing even though they don’t expect to need to do it, perhaps project reviews should prepare for pausing/stopping projects even though they don’t expect to do so very often. After all, you probably buckle up your seatbelt every time you drive your car even though you don’t expect to have an accident. A good project gateway could perhaps be seen as the project’s emergency brakes, seatbelt and airbag. Where braking is necessary, it’ll be much more comfortable for everyone involved if it’s done early and gradually!

If your project gateways are already working like this, that is fantastic. If not, perhaps this is food for thought

Do you realize that relationships are BAs bread and butter?

Written by Tom Henricksen on March 30, 2022. Posted in Articles.

Working as a developer for over twenty years I have noticed developers lack social skills. Now I know you are shocked! You probably spilled your coffee when you read that.

As a Business Analyst, you may take your social skill prowess for granted. As Epictetus said, “It is impossible for a man to learn what he thinks he already knows.” Let us revisit those skills now.

Re-Focus on Relationships

It can be helpful to review these skills periodically. We can fall into the trap of complacency. Use a few basic questions to evaluate your progress.

Who are my most important business relationships?
How am I investing in these relationships?
What value am I bringing to this relationship?

Similar to the agile retrospective we can have a relationship retrospective. Check-in with your most important people. See how things are.

Occasionally things can seem fine at the surface. Of course, when we dig in we find something different. Perhaps the relationship can be strained. The person may feel you are taking advantage of them.

Overlooked

My mother would often dispense wisdom when I was growing up. She was a teacher for many years. She shared this one once, “Secretaries make things happen.”

As a kid, many people would overlook the school secretary. Using my mother’s advice I made sure to stay on the good side of Mary.

Mary was our high school secretary. She could put in a good word for you in case you got in any trouble. That may have happened to me a few times. Mary was a life-saver!

Are there any professional relationships you are overlooking? Perhaps you need to patch things up with some of the testers. Team harmony is vittle to a smooth project.

Have a plan

A few years ago I was fortunate to work with a transformational leader. He led a technology team. John was his name. He saw the potential to change the way his team worked.

John brought me into his office. He said to me, “Tom technology people can be a bit transactional. They get asked to fix a problem and they do. Similar to the way a bank teller gets a check and deposits the check.”

“Yes, I see that, but how is that an issue?” I said to John.

“Bruce just visited our biggest center. He upgraded the two servers and got on the plane to go back home. A day later the community director called me and asked why he didn’t complete the upcoming maintenance patching. Bruce never spoke to him.”

“Tom I want my team to be more like financial planners. A financial planner builds relationships. Then they can anticipate needs. I want you to help change my team to think like financial planners.”

John then shared with me a plan on how we could transform his team. He outlined how each time his team members traveled they would talk to the community directors.

This would help them build relationships instead of just fixing the problem. John wanted his team to build in time to connect. Have a plan for relationships.

In summary, as Business Analysts we should not overlook the fundamental aspect of relationships. Don’t leave them to chance, have a plan. Keep them in focus as they are your bread and butter!

Tom Henricksen is a Technical Professional and Human Skill Enabler and you can contact him on LinkedIn at https://www.linkedin.com/in/tomhenricksen/

The Delicate Balance

Written by Liina Pruulmann on March 1, 2022. Posted in Articles.

As a new analyst in the User Account Management team in Playtech I often find myself making a challenging choice. On the one hand there is the option to build a new feature, create a new configuration, etc. On the other hand, there is the option to create a new automated rule and custom tags to simulate the same outcome. The dilemma of dev vs no dev. And it is often not a clear-cut case.

As fellow analysts or product owners know, a proper feature for a set of use cases is… neat and tidy. It is easy to refer to when answering questions from users. It can be reused. It can be further developed. It feels like something got done.

The challenging alternative is to choose an already existing powerful tool (for example Automation Service Engine) that can be used to create business rules based on defined parameters. This is awesome! No more dev for us. We have created a tool that replaces custom dev. But wait, we need to do some small tweaks to this tool before it becomes capable of achieving the desired outcome.

After having done some soul searching on this eternal dilemma, I have found it comes down to these 5 considerations:

Backwards Compatibility

We have 118 operators with a total of 385 brands. When adding new configuration options, we need to be extra careful to make sure that current setups do not suffer. Often this means we need to come up with a default value that would maintain the status quo in addition to the new value that would enable the new behavior. Boy have I ever felt the caricature of “repairing an airplane mid-flight” to hold truer.

Let’s take Self-Exclusion for example. It is already quite complex and at the same time business-critical. If we make a minor change and this feature then starts acting even in a slightly different way, we’ll potentially have several major regulatory breaches that can end up in large fines or even lost operating licenses for whole countries.

Futureproofing

If we invest time here now, will it be reusable for future cases? Will there be similar requests in the future? In what ways do we need to design flexibility into the feature? This comes down to the infamous “gut feeling”. I have a gut feeling that in the future we will see a lot more focus on active intervention in regulations. Licensees would have to actively monitor their player base to determine at-risk players and proactively suggest different self-governed limits or indeed apply limits without consent (but still with a duty to inform). This would mean a well-rounded interface that would incorporate communication features, at risk player discovery (using machine intelligence), flagging said players, and responsible gaming features well at hand. This would be a considerable interdisciplinary effort. Would it be worth the investment?

Maintainability

We are the guardians of the system. We should know the best ways to solve business and regulatory requirements by using either existing features or creating new ones where appropriate. The more ad hoc solutions we offer, the more cumbersome it becomes to maintain. The limitations of the human memory in combination with the problems of organizational memory mean we would soon have no overview how different configurations are achieved or know how the system behaves when using combinations of said ad hoc solutions that are not specifically designed to work together. I would argue that if there is a combination that is only meant to work together and excludes all other options, then this can effectively be considered a new separate feature. The goal is to have fewer dependencies and fewer configuration options within one feature.

Fast Release Cycle

Every party involved in software product development wants to have a solution that requires the least amount of work possible. Our time is extremely valuable, and the cost of missing opportunities is even higher.

The time constraints also come into play regarding go-live dates, certification deadlines and so on. If there is a faster option for developing a new feature that must be adopted by all parties down the line… often the best solution is to go ahead with the workaround. Sometimes the workaround becomes permanent, sometimes we get to phase two.

Adaptability

I am picturing the IMS setups of existing licensees as brides on their wedding day. It took months of preparation and multi-party negotiations to get every detail right (and somehow still over budget?) If possible, no-one must touch the setup that works. Do not fix what is not broken, right? Mostly people are just too afraid to upset the bride.

But it is also our hope that when we create a cool new feature that would benefit existing licensees, they may become interested in improving their business processes, security, or customer experience. Indeed, they are paying for a continuously developing platform so they can benefit from new features, and we are actively promoting them.

These features need to be extremely easy and fool-proof to adopt. If a client gets burned once they will be even more hesitant to change their working setup the next time.

No Clear Answer

Usually, you can get some sort of an answer to almost any problem by creating the famous Pros and Cons table. The problem is – I cannot draw a table (I tried) with all these considerations and two columns – one to tick if in favor of dev and other for no dev. It is not a binary choice, but more like a scale. Sometimes the scale is only slightly in favor of one or the other in each aspect, sometimes more decidedly so.

Finally, I would like to give you some insight into how I adapted to this situation – maybe fellow analysts will recognize the steps below:

A new-to-me, established, fully functional, super customizable system. There cannot be a problem too big that cannot be solved with a few simple tweaks.
Uh-oh. Tweaks are not enough. New features are the order of the day! Everything should be solved with new features.
Wait… could we add a small checkbox here in this feature to create a configuration option?
Too many configurations! Who on earth can keep track of them all?
Aha! A rule engine… and tags! Let’s see how many problems could be solved just by using them?
Write an article
Continue to learn and develop.

Approaches for Being a Lead BA

Written by Aly Cassam on January 27, 2022. Posted in Articles.

You’ve worked your way up the BA ladder – started as a Junior BA, then a BA, then a Sr. BA, and now you’re a Lead BA on a project working with other BAs. What do you do? This article focuses on some of the Do’s and Don’ts of being a Lead BA. Some of it is science and some of it is art.

Requirements Governance:

1. Who do you take direction from your PM or your BA Manager:

The first place to start as a Lead BA is establishing your own personal Requirements Governance. Who do you provide status updates to and who do you take direction on requirements from – PM or your BA Manager? The scenarios I’ve encountered are:

You as the Lead BA take your BA requirements direction from the PM and provide status updates to your BA Manager.
You as the Lead BA take your BA requirements directly from your BA Manager and provide status updates to your PM.
The third and most often scenario is where both the PM and your BA Manager are of the opinion that you take requirements direction from them and provide status updates to the other.

Tip: Right at the beginning of the project start the conversation with your BA Manager and clearly establish the relationship you’ll have with him or her and with the PM (in my experience coaching BAs too many Lead BAs don’t have the conversation upfront and then find themselves in a bind when scenario C) above becomes an issue during the project itself). If the answer is taking your requirements direction from them, set up a short meeting with your BA Manager and the PM to establish this relationship as PMs generally don’t like that arrangement, and it’s best to get them to discuss it face to face. If the answer is taking your requirements direction from the PM, then simply follow-up the meeting with a confirmation email to your BA Manager and just let your PM know that you’re effectively going to report to them and take, where appropriate, BA approach direction from them.

2. Establish your role as Lead BA on the BA team:

Make sure it’s clear to the BAs you’ll be leading that you are the Lead BA, and they will work with you in that capacity. A couple of ways to communicate this:

Ensure you’re called out on the project governance as the Lead BA and ensure the BAs you’ll be leading review the project governance
Where you’re taking your Requirements direction from your BA Manager have them send out an email to the BAs you’ll be leading that you’re the lead and that you’ll be guiding the approach etc. to the Requirements deliverables

3. Start by learning about your BAs:

At the beginning you’ll need to establish how experienced the BAs are with eliciting, documenting, and analyzing requirements, how familiar they are with the project subject matter, etc./ by scheduling quick little chats with the BAs you’ll be working with

If you’re dealing with Sr. BAs with lots of experience, then your focus with them will be on making sure things are going smoothly and that they working to the timelines for their requirements work packages; You can give them fairly large and complex requirements work packages
If you’re dealing with more Jr. BAs then you will be in a more guidance/ mentoring mode – periodically reviewing their requirements and providing feedback, mentoring on approach to different types of requirements such as documenting process flows and business rules, etc.; Initially limiting the scope of their work packages to small well-defined pieces of requirements; have little chats with them about how things are going

4. Develop a view of the requirements work packages:

Typically, a group of BAs is assigned to a project because the project is complex and there are multiple “groups/ categories” of requirements that need to be created to deliver the scope of the project. At the outset understand the drivers and objectives of the project and establish a view of the requirements work packages. Some examples of this are:

a. Achieving compliance with regulations or another compliance-related purpose:

1. You may need to look at work packages focused on complying with different sections of the regulations
2. If the compliance covers multiple departments or Lines of Business (LOB) you may need to focus on requirements for each department/ LOB to comply with the regulations

b. Developing and implementing a large technology system or platform:

1. 1. You may need to look at requirements work packages focused around different groups of users with the system – for example if it’s a workflow system you likely have work packages for customer-facing components, back-office-facing components, etc.
  2. You may need to look at requirements work packages focused on different functional features. For example, a customer-facing platform for a direct investing platform may consist of trading-related features, viewing account holdings, researching different securities, etc.

5. Managing the requirements work packages:

a. Establish a view of the project timelines with respect to the requirements work packages based on their complexity etc. I prefer a matrix like this to do so (using the direct investing platform as an example) based on the requirements lifecycle – plan, elicit, analyze, document, get sign-off (note do this in Excel or Project to track progress, etc.)

	Plan	Elicit	Analyze	Document	Sign-Off
Trading requirements	01/01/22 to 10/01/22	10/01/22 to 25/01/22	25/01/22 to 02/02/22	02/02/22 to 16/02/22	16/02/22 to 28/02/22
Security Research requirements	01/01/22 to 10/01/22	10/01/22 to 25/01/22	25/01/22 to 02/02/22	02/02/22 to 16/02/22	16/02/22 to 28/02/22
View account holdings requirements	01/01/22 to 10/01/22	10/01/22 to 25/01/22	25/01/22 to 02/02/22	02/02/22 to 16/02/22	16/02/22 to 28/02/22

b. Based on what you learned about the BAs you’re leading assign them to different work packages – and monitor their progress on their work packages against the. I’ve found the best way to keep track of this is using a matrix like this that I update on a weekly basis:

Legend:

P – Plan, E- Elicit, A- Analyze, D- Document, S- Signoff

	BA1	BA2	BA3
Trading requirements	P – Jan. 1/22
Security Research requirements		P – Jan. 1/22
View account holdings requirements			P – Jan. 1/22

With these 2 matrices, you can keep track of who’s doing what and how they are doing against the target dates so you can provide status reports to the project team as required.

6. Monitoring progress and connecting the BAs as a team:

The most effective approach that I’ve found to monitor the progress of my BAs is to hold weekly meetings – with a twist. Most people just do a status check-in during their weekly meetings – how are you progressing against your timelines. I believe that weekly meetings are a good chance for the BAs to inform and help one another. I encourage them to talk about challenges they are having – someone else in the team may have encountered this and have a solution/ approach to tackling it. I encourage them to talk about effective approaches that they’ve found to doing things that may be helpful to other members of the team. Finally, I ask each BA to give a brief overview of the requirements they are working on. As most projects with a BA team have a common goal – by talking about requirements it will quite often identify synergies or conflicts between requirements/ work packages that will help move the project forward more efficiently.

Conclusion:

Hopefully, these approaches will help you become a more effective BA Lead. There are lots more approaches and in future articles, I may expand on them.