Tag: Planning

Improve Prioritization Using a Combination of Techniques

Written by Steve Jones on September 28, 2022. Posted in Articles.

Software development projects have a long history of unsuccessful delivery for myriad reasons. A lack of success is often determined by what didn’t make it into the final product release; like a core functionality, while some enhancement items did make it in. This begs the question, “Why weren’t all of the core capabilities the focus until they were complete?”

Rarely does everything in the requirements get implemented, so knowing the core capabilities is necessary to keep from getting derailed by enhancement requests. When a project includes multiple stakeholders, it isn’t uncommon they end up fighting for the wrong thing as it relates to the project, “their stories.” What gets lost in all the fighting over each stakeholder’s “priorities” is the real goal – achieving the right outcomes for and by the project.

What’s the problem?

TLDR: There are challenges when using just one prioritization technique to provide guidance of what to work on next.

User stories and requirements can be prioritized using several different techniques (Ranked Order, MoSCoW, Scaled, $1/$100, High/Med/Low, Story Mapping, Weighted Shortest Job First [or WSJF], to name a few), with different benefits and drawbacks to each of them.

Ranked order, i.e., setting out to identify the explicit order to be worked, is a very time-consuming challenge. Changes, whether from business decisions or technical limitations, can happen at any time during the project and cause a reshuffle every time they occur.
Using fixed amount methods to prioritize, such as the $1 or $100 methods, are good at giving clear indications of importance by virtue of the highest number. Fixed values limit the number of stories that can be created without resorting to restructuring the whole valuation system. On reviews and revisits, any change forces a recalculation of many stories.
Categories produce multiple stories with the same value (many ‘High’ or ‘Must have’) that do not always provide enough information to know priority. When there are so many with the same value, it forces a break in the effort to know what should be worked on next, unless a tie-breaking method is already defined.
Story Mapping helps manage the big picture of the project since it displays all themes / activities of users. The themes and activities are ordered along a top row, then broken down into smaller stories and ranked in priority. Early in the project, the number of stories and ranking effort is focused, more easily identifying high value functions / stories.
Weighted Shortest-Job First, WSJF (pronounced wiz-jif), rates each story on business value, time criticality, and risk reduction / opportunity enablement (the business valuation, known as ‘Cost of Delay’), as well as factoring in the IT effort to deliver the story. With several criteria getting a valuation for each story, it becomes easier to see the highest business priorities to work on next. This can still mask the core needs that must be delivered.

Another challenge to prioritizing arises with many of these techniques when new stories are added. Sometimes a key requirement is missed during early analysis or through story decomposition and story splitting. Other times, demonstrations of work inspire new requests or research identifies a new need. How are the new stories valued, ranked, categorized? Do the newly added stories all get the same value as the original when split or does the ranking need to be done again? What becomes of highly valued stories which are just enhancements? Enhancements may have higher business value than some core technical stories. Some of these techniques handle additional stories more easily than others.

Maintaining prioritization is a challenge in itself

Capturing all this prioritization detail can be a frustrating challenge but maintaining it over time is just as frustrating. If you have a software tool that can automatically adjust rankings, some of these techniques may not be as much of a problem. But what if you are using physical cards or sticky notes to keep it all organized? It becomes a tedious task to manage the series, which will drive some to stop updating after a while, especially after repeated changes. Choose your method of prioritizing wisely, you will likely use it often.

How do we solve it?

Story Mapping is an effective approach to keeping an eye on the big picture goals without getting lost in the details. This is beneficial as it provides a more complete end-to-end view of the project, in addition to providing a view of the lower-level details in accompanying stories. Each of these stories can then be identified as a core ‘must have’ vs a ‘nice to have’ enhancement.

Combining multiple techniques simplifies project priority determination. For example, utilizing the business valuation portion from the WSJF does a good job identifying the value for any given story. The valuation can be used for easier ranking without the need to constantly revalue everything below (see Figure 1). In addition to identifying the value of each story, it is very helpful to identify what is needed for core delivery and what is enhancement. When splitting a story, make sure core functionality is clearly differentiated from what may be an enhancement.

Taken in combination, stories are identified as a core delivery need or enhancement AND with each story’s individual business value (the number inside the ovals in Figure 1). While there may be enhancement stories with high value (sometimes viewed as the next shiny new thing), they may not be core functionality. Keeping the high-level view of core delivery items distinct from enhancements enables the focus to stay on outcomes. This perspective can be crucial to maintaining reasonable prioritization efforts in limiting unnecessary re-work of rankings, and identifying enhancement stories to address after all the core functionality is complete.

In the end, using more than one technique to manage project and product priorities ensures that the team is focused on getting the right overall outcomes, instead of persistent debate over individual stories. Practice quality communication and utilize your tool kit to experiment in finding what works best with your stakeholders and team.

Constructive Conflict Is Better Than False Agreement

Written by Adrian Reed on July 21, 2022. Posted in Articles.

Over a decade ago, I was in a workshop with a range of different stakeholders.

Everything seemed to be going well, and people seemed to be agreeing and we were even running ahead of the meeting schedule. Around halfway through the meeting a particular issue was being discussed, a conclusion was going to be drawn and a stakeholder interjected strongly and firmly with two powerful words. They simply said:

“I disagree”

I remember being taken aback by the bluntness. I live in the UK and our communication style is somewhat indirect most of the time. It’s far more normal to say “Hmmm, interesting idea, or what about…?” which is code for “That’s a crazy idea”. Or often the temptation might be to revert to the ultimate British stereotype and apologize “Sorry to be a pain here, but I’m not sure I entirely agree”. I’m sure British culture is not the only one that has such indirect nuance.

The reason I remember this meeting so vividly, even more than a decade ago is that those two words initially made people visibly uncomfortable. Someone was breaking the consensus; they were “creating conflict”. Yet that wasn’t the intention, and of course they didn’t just say that, the stakeholder went on to explain the source of their disagreement, and what they proposed instead. Thirty seconds later (once the stakeholder had explained themselves) any feeling of discomfort gently dispersed. What’s more, other attendees of the meeting started to question things, interject and show disagreement. One stakeholder questioning a decision had the apparent result in creating perceived permission for others to do so. And you know what? I am convinced that the output of that meeting was better as a result.

Don’t Let Conflict Fester

Many of us have been taught to consider conflict as bad and consensus as good. I suppose that is true in an ideal case, but if you’re working on any kind of large scale change how realistic is it that every stakeholder is really going to be ‘on the same page’ and in total agreement? If a government implements a new type of tax and requires businesses to submit more information, there’s unlikely to be a standing ovation from business owners. Yet that doesn’t mean that their input isn’t valuable—I would go as far as saying it’s essential!

Our fixation with consensus can lead to a situation where we achieve illusory agreement, a veneer of satisfaction. Dissenting voices get marginalized, as they’ll never agree (so why spend too much time asking them?). We carefully facilitate meetings so that there aren’t big disruptive arguments, as we’re desperate to hit all of the aggressive (sorry ‘ambitious’) project deadlines. Yet this dangerous glossy veneer is very quickly broken when people start to interact with the product or service that we deliver. All we’ve done is defer the conflict to an even less convenient time, often a time when there’s so much political capital riding on the ‘solution’ that’s been designed that there’s no appetite to change it.

Cultivating Constructive Disagreement

As business analysts, we can help avoid these situations. We have the opportunity to create space for constructive and respectful conflict, and we should certainly avoid us or others sidelining people just because they have contradictory views. In our analysis activities we should encourage constructive and respectful disagreement.

Taking an example, when setting up a workshop we have the perfect opportunity for creating the opportunity for a robust and respectful discussion. We can lay down an appropriate set of ground rules that allow for differences of opinions to surface. I’ve found myself opening workshops saying things such as:

“This is a controversial topic, and there are bound to be some differences of opinion. That’s to be expected. With that in mind please do speak up at any time and add your view, but please do be prepared to elaborate on it. Keep in mind I’ll be facilitating fiercely but fairly—and there might be times when I need to ‘park’ your item for later discussion. It absolutely won’t be lost, we will come back to it, but please don’t be offended if I need to do that.”

When we facilitate, we can actively prompt, asking questions such as:

“We seem to have complete agreement here; are there any contradictory thoughts. What have we missed?”

Ensuring that stakeholders have the ‘air time’, and ensuring that the most bombastic attendees don’t steal the limelight is crucial. Using a range of tools and techniques in the workshop to consider not only what we want but also what could go wrong can be useful too. Even just asking a question such as “That seemed too simple, might we have missed something?” can help.

Most of all, cultural nuances aside, we shouldn’t be afraid of the concise clarity of an expression such as “I disagree”. When someone says it they provide us with a gift, an opportunity to better understand them.

Best of BATimes: Deal Breaking Soft Skills – The Essential BA List

Written by Usman Haq on July 7, 2022. Posted in Articles.

If you don’t have the right soft skills, you will struggle as a BA. Business domain knowledge and hard skills can be taught.

But finding a BA with the right set of soft skills can be a deal breaker for employers. And no, it’s not just the ability to read, write and converse. So which soft skills do you need?

Heads up

In this post I will be going over the soft skills which are essential for a BA.

Communication

Being a good listener, showing that you are patient and empathetic. Actually listening to the DEV team when they say a feature can’t be achieved. And being transparent with the business when explaining the same.
The ability to explain difficult (and sometimes simple) concepts/ideas/justifications (anything really) at all levels.

For example, walking through a business process with your DEV team. Clarifying business terms and ideas which they not be familiar with. Translating that into how the system works and explaining the value provided to the business.

Being able to articulate answers to questions clearly and clarify points on the spot. For example, not confusing the business with technical terms. Explaining concepts in a way that they will understand. Even if you don’t know the answer (rather than making something up) say that you will find out and get back to them later (and actually do that).

(Difficult) Stakeholder Management

Managing your emotions. Not all stakeholders play nice. You will always (always!) have one or more difficult stakeholders. You need to understand their motivations and why they are being difficult. The key is to maintain your professionalism and not let your emotions get the better of you.
Influencing. This also includes influencing without formal authority, persuasion and negotiating. Your reputation helps significantly here. If you are known to get things done and do what’s best for the company/client, your stakeholders will be more inclined to see things your way.

Managing Expectations

Showing you are in control. The business/stakeholders/your boss needs to know you have a handle on things. The worst thing you can do is pretend that everything is ok but in reality, it’s all falling apart. You must be clear about your workload and ability to deliver on time. If things are slipping, make sure you have evidence why. For example, maybe the business is not cooperating during requirement’s session. Possibly the vendor has screwed up somewhere. Maybe you have too much on your plate and you need to offload some work.

Diplomacy

The ability to understand office politics. For example, knowing who can get things done for and who always plays hardball.
Conflict resolution. Ideally conflict mitigation. Knowing when a situation can get out of hand and how to resolve it quickly.
Knowing what to say and to who. You will probably know certain people in your organization who you will want to avoid unless you really (really!) need to speak to them.
Having the ability to speak the truth and gain trust but also not “putting your foot in it”.
Learning how to tell people in power that they are wrong without them feeling like they are!
Not oversharing information to the wrong people and opening cans of worms which can impact you later.

Analytical Thinking

Being naturally good at working out problems. Being able to dig deep to find out the the root cause of an issue. (link to root cause)
Reading people/understanding people. The ability to sense when stakeholders are reserved and giving them the power to speak up and be heard.
When a stakeholder asks for something, being able to understand what they really want but are struggling to convey. Working out when people are masking the truth or too scared to speak up.

Adaptability

Handling pressure and stress. For example, working towards deadlines which might change at the last minute. And having to drop things and work on something else more urgent.
Dealing with WTF situations. For example, being dropped into a major production issue which is affecting the company’s revenue and the stakeholders are looking to you to get them out of it.

Relationship Building

More than just chit chat. You need to build effective working relationships by being known for:
- Getting things done
- Doing what you say you will do
- Going the extra mile when needed
Being able to call in favors based on trust
Knowing who to ask when you need answers to difficult questions
Know who to ask (if they don’t know) to find out who else might have the answer to your questions

Leadership On Demand

Leading a group of BAs (e.g. in your managers absence), leading workshops and coaching junior staff

In this post I went over the soft skills which are essential for a BA. Effective soft skills are often taken for granted. I was guilty of this myself early in my career. Over time I have worked hard to develop my soft skills (and still continue to do so). Are there any surprises in my list? Anything you would like to add?

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