Requirements are a Contract

Written by Yvonne Harrison on December 6, 2023. Posted in Articles.

Ensuring that project requirements have been understood and agreed to by all stakeholders is one of the foundations of a Business Analyst’s work.

However, that understanding and agreement from the stakeholders doesn’t always translate to the successful delivery of the project. Even though everyone on the business side has confirmed that the BA understands their wants and needs, those requirements can wind up being misinterpreted (or outright ignored) once they reach the technical team.

No matter how careful the BA has been, things seem to slowly and surely fall apart. It seems to make no difference if the project is using agile, or waterfall, or the requirements are documented in Word, or Excel, or in requirements management software such as IBM DOORS, or SPARX Enterprise Architect, or JIRA, or written on a sticky note. The results are depressingly similar from project to project.

Whatever is presented in the demonstration never seems to be what anyone in the business asked for. Which usually becomes the Business Analyst’s problem. Somehow the BA didn’t do enough documentation or missed something.

Over the years, I have realised that no amount of documentation, meetings, or stand-ups will save the BA. That’s because the problem is not with the requirements or the Business Analyst. The problem is with the quality of the technical team.

Before anyone gets upset, no, I am not insulting the technical team. What I’m suggesting is that most projects are a mixed bag of personalities and experience. There might be new junior developers, overworked senior developers juggling multiple projects, people who don’t want to read the documentation, and sometimes, people who outright ignore the requirements because they have determined, “that’s not how the business works.” The project is either over time and out of budget (or both) but even then, can never seem to finish.

No one seems to discuss the impact the technical team has on the requirements themselves and the amount of stress it places on the Business Analyst.

Think like a lawyer

What can a BA do to reduce the pressure they’re feeling?

In my opinion, a BA may find it useful to think like a lawyer.

A lawyer researches the parties involved in a contract. What are these parties like? Are they prepared to negotiate, or do they dispute everything? As a BA, you do have one advantage in that you will have communication skills and you can deal with different people and personalities. This allows you to figure out who you may be dealing with. What are they like? How experienced are they? Are there issues within the team? Although you could argue that this is just a RACI matrix – this goes one step beyond. You don’t care if they’re responsible, accountable, consulted or informed. You want to know how likely it is that the project will wind up in a mess. Something the Project Manager is unlikely to acknowledge until it’s too late (depending on the PM’s experience).

This changes the focus because not only are you eliciting your requirements from your stakeholders, but in the background, you’re also trying to determine what the technical team is like. The makeup of the technical team is going to help you determine your deliverables.

Alistair Cockburn states in the introduction in Writing Effective Use Cases, “A use case captures a contract between the stakeholders of a system about its behaviour.”

Decide on the type of contract

Keeping with a more legalistic view of requirements, the Business Analyst can then decide if the contract should involve a high degree of ceremony in which requirements are meticulously explained and documented, formally signed off, with meetings scheduled to discuss these requirements in detail. Or whether you can take an approach that is highly collaborative and relies on face-to-face chats between the team and the BA, with light touch documentation (some user stories, and a couple of whiteboard sessions).

In other words, how you construct your contract, will depend on how tightly you need to bind the technical team to that contract. And the type of contract the binds the two parties together will depend on how much you trust that other party. If you trust the other party, and you’ve known them for a while, then a handshake agreement may be all that is needed. A handshake agreement tends more towards an agile approach with some user stories and daily discussions, over and above a standup.

If you have less trust, or the project has a lot riding on it in terms of its budget or the features being delivered, you may decide on the equivalent of a legally binding contract. It may consist of several documents, and the documents are all formally signed off. Like all weighty contracts, you need to write in a manner that removes all ambiguities.

Much like a lawyer, your job is to ensure your wording is not open to misinterpretation or provides a way for the technical team to deliver something else entirely.

And if they do, you have your signed off documentation in which you can point to it and politely ask why the clause was ignored – and how they’re going to remedy the problem. Because the requirements are a contract. One that all parties need to adhere to.

Secure or Sorry: From Gym Lockers to Cybersecurity

Written by Adrian Reed on November 30, 2023. Posted in Articles.

I’m a member of a local gym, and a few weeks ago I noticed that they were maintaining the lockers in the changing rooms. The lockers are pretty standard metal boxes, and members bring their own padlocks for added security.

I’d noticed for months that the latch mechanisms had been getting very loose, so I was glad to see maintenance happening. The staff member doing the maintenance was chatting to another member, and I overheard him say that there had been a whole series of thefts the previous week. Accordingly, they were ramping up security, including turning on the keycode lock on the changing rooms (members each have a PIN code which can be used to access the facilities, but was usually switched off during the day).

I suddenly felt a real perception of risk, to the point that I decided not to leave my house keys in the locker, but take them with me onto the gym floor. I’m now even more cautious when closing my padlock, to make sure it’s properly secure.

The Horse Had Left The Stable

While all of those personal security measures are useful, the gym (and I) were only prompted to review our security posture after an incident had occurred. The thieves had probably long gone, and had moved onto a different gym. Perhaps they even tour the country, buying day passes, finding the gyms with weak security. Who knows. Not only this, but the gym had increased its security, so my possessions were probably the safest they’d ever been. Yet I felt the most uncomfortable I ever had.

Ironically, the time I was most at risk (the previous week, when security was lapse and thieves were at the gym) I was blissfully unaware, the risk wasn’t particularly on my radar. I may have been happily running on a treadmill at the very moment a thief was breaking into a locker and stealing someone’s property.

This pattern of the gym increasing security after an incident occurred might be seen as a classic case of ‘closing the stable door after the horse had bolted’. However, it’s not that simple—reacting to a security threat after an incident occurred is still valuable, as it will prevent a similar thing from happening again. I suppose it is more akin to closing the door after one of your three horses has bolted. Not as good as closing the door earlier, but better than continuing to leave it open…

Predictable With 20/20 Hindsight

The thing which struck me about the locker thefts is that it was completely predictable with hindsight. The latch mechanisms on some lockers were so loose it’s easy to see how they could be overcome. Not only this, a culture of trustworthiness (which is lovely) had emerged. People would leave their expensive coats out, and some people wouldn’t even use padlocks at all.

As my father used to say “it only takes one bad apple”. And as time goes on, it seems statistically likely that the bad apple will emerge.

It’s Not Just Lockers: Information & Cybersecurity

This pattern of trustworthiness and complacency doesn’t just exist in gyms, it can also be an issue within organizations. If you haven’t had a data breach, then security of data might seem an irritating formality, or it might not feel as ‘real’ as some other more proximate risks. However, the fact is that there are hostile actors out there targeting companies just like yours and mine.

I’ll bet in most organizations there’s at least one application that is creaking at the edges, is out of support (or nearly out of support), or an application where there’s a maintenance patch needed, but that’s not seen as a priority just yet. Or an application that’s been customized so much it’s not on the official upgrade path any more. Upgrading it or replacing it has always been seen as important but not urgent, so it’s left there, collecting more and more dust. Might there be some security vulnerabilities there? Perhaps it’s like an insecure gym locker, fine for the moment, but once a ‘bad apple’ finds it there will be chaos… and that single vulnerability might gain them wider access to all sorts of systems and information.

It’s not just about customer data either. Do you know what your organization’s key intellectual property is? Where it’s stored? Who can access it? Where it’s backed up and archived? In many organizations it’s spread out, with key information that yields competitive advantage mixed with more routine stuff, all dumped in a folder or repository of some type… Hopefully someone from ‘corporate IT’ is backing it up. Let’s hope so, eh?

Security Matters: Business, Process & IT

There is sometimes a perception that information and cybersecurity is an ‘IT thing’. The reality is so much wider than that. The weakest link might not be the tech, but the person operating the tech who receives a call out of the blue by someone they believe to be a colleague (but is actually a hostile actor engaging in ‘social engineering’ to gain information).

This has wide implications for business analysis. Security needs to be built into IT systems and processes from the very beginning. It’s important to think “who might be trying to gain unauthorized access to this, how would they do it, and how will we prevent it?”. It’s important to think about the types of information and data held, its sensitivity and the impact if it were to be damaged or disclosed. This will lead to specific requirements and acceptance criteria around these aspects. It will likely lead to a BA asking challenging questions, which might include “is this the right thing to do, right now, when we have a security vulnerability over here?”

Most of all, while things might be calm now, there might be a storm waiting round the corner. It is the calm times when a little investment in the ‘important but not urgent’ will save a lot of headaches in the future. And surely that’s worthwhile?

The Value of Business Analysis Competencies in the Successful Delivery of IT Projects.

Written by Nosa Adagbasa on November 29, 2023. Posted in Articles.

Several schools of thought have proffered reasons why projects fail; notable amongst these are studies by Forbes, the British Computer Society, Gartner, and many others. Generally, the causes of IT project failures have been described as ranging from poor business cases, requirements management, project management, talent, and poor processes.

Conversely, certain factors, which are described below, can be identified as factors responsible for successful projects.

BA competencies are a set of knowledge, behaviour, attitudes, and skills that enable a business analyst to perform business analysis successfully and efficiently. These BA competencies can be mapped to the factors that guide the successful delivery of IT projects.

Accurate problem definition and analysis

This is central to delivering successful projects as it entails proper identification of problems, the scope, and thoughts around solutions. One major reason for IT project failure is that the business is often focused on the consequences or symptoms of an underlying problem and quickly directs technology to resolve these symptoms. At best, the result is an expensive IT solution that is sparsely used by the users, who often find workarounds or, at worst, IT projects that fail.

BA Competency: Analytical Thinking and Problem Solving

This competency employs critical thinking, system thinking, and problem-solving techniques, amongst many others, to help carry out root-cause analysis and produce problem statements that help correctly identify a problem.

People

People are an organisation’s greatest asset. Several schools of thought, including Herzberg’s, Maslow’s, etc., have carried out studies on employee productivity. Too often, while embarking on IT projects, the focus is on the technical skills of the project team, while knowledge around behavioural attributes, emotional intelligence, and concepts that affect productivity resides with the human resources team, who are seldom part of the IT project team.

BA Competency: Behavioural Characteristics and Personal Quality

BAs understand behavioural characteristics and human resources concepts of motivation, productivity, and emotional intelligence and constantly need to keep these in sight as they seek to understand the problem and define relevant requirements for a successful solution.

Knowledge of organizational structure and culture

While structure deals with norms, rules, and policies, culture is concerned with organisational values, behaviours, and attitudes, and both can affect the agility of project delivery. Thus, an optimal combination of the two is vital to successful project delivery.

BA Competency: Business Knowledge

This involves the application of business acumen, industry, organisation, appropriate methodology, and solution knowledge. Peter Drucker famously declared that culture eats strategy for breakfast, buttressing the importance of a thorough understanding of business to aid organizational success.

Effective Communication

This is the process of exchanging ideas, thoughts, opinions, knowledge, and data so that the message is received and understood with clarity and purpose. The challenge for many businesses is that this is not recognised as a skill that goes beyond writing and speaking. It involves non-verbal communications, listening, and analysis. When this is lacking in an IT project, the risk of failure is increased.

BA Competency: Communication Skills

Business analysts act as intermediaries between the business and IT and, as such, are trained in effective communication skills. They understand business and IT concepts and help to facilitate and interpret conversations to help all stakeholders deliver successful solutions.

User needs and top management support.

IT solutions are intended to meet user needs; however, a major reason for IT project failures is half-hearted support from top management. Often, top management is concerned with strategy and has a broad view of concurrent projects without knowledge of user needs. There is therefore a disconnect between project delivery and top management, with the resultant effect that projects don’t get the full backing required for success. Support is usually given in principle but lacking in practice as top management is often far removed from the projects.

BA Competency: Interaction Skills

Business analysts not only act as the intermediary between IT and the business but can also act as an intermediary between top management and the business. With their interaction skills, they can drive conversations among stakeholders and ensure that difficult questions are asked and resolved to ensure the successful delivery of projects.

Business-Led Modular Technology and Data Platform

Organizations that intend to deliver successful IT projects need to have a modern technology architecture driven by business needs, as evidenced by data. Advances in technology mean that businesses no longer have the choice of being either technology-savvy or operating on the fringes of the technology spectrum. Technology drives agility in today’s business environment, and the influx of AI makes it more expedient that businesses that want to thrive will need to invest in sound technology architectures and platforms.

BA Competency: Tools and Technology

This BA competency fosters the knowledge and use of tools and technology to drive productivity. From the use of general communication and office productivity tools like ‘Teams, Slack, etc. to business analysis tools like Jira, Azure, Visio, etc. to AI tools like Chat-GPT, Google Bard, Slides AI, etc., business analysts are equipped to be versatile while continuing to broaden their toolset.

Clear Process Flows and Business Requirements Management

This covers the end-to-end process of delivering an IT project; it encompasses identifying the right requirements, managing stakeholders, ensuring an accurate depiction of information flow through the organisation, and managing change.

BA Competency: Professional Techniques

This deals with delivering excellence by design. It is an aggregation of several BA competencies with a focus on ensuring that excellence is delivered at every point of the customer journey. This implies understanding an organisation in terms of its people, processes, steps, and the data required to make each step as efficient as possible.

Concluding Remarks

Historically, the rate of IT project failures has been high; however, opportunities now abound to turn the tide. As knowledge and awareness continue to increase and the business analysis skillset becomes more mainstreamed across organisations, there is an opportunity for business analysts to hone their craft, be more visible, and help stem the tide.

Lost in Translation: The Perils of Ambiguity in Business Communication

Written by Adrian Reed on November 22, 2023. Posted in Articles.

In recent years, I’ve traveled a lot less than I did before the pandemic. One thing this has led to is me seeing processes and practices with fresh eyes. When you travel regularly, the novelty wears off and a sort of ‘autopilot’ kicks in, and a period of not traveling means that everything is less familiar and more open to scrutiny.

I was recently thinking about the questions that are commonly asked when checking in bags before a flight. I can’t even remember if these questions are asked verbally any more, or if there’s some sort of sign or declaration, but there certainly used to be questions such as:

“Have you left the bag unattended at any time?”
“Did you pack the bag yourself?”

I suspect, like many people, if you were asked these questions a semi-autopilot would kick in and you’d say ‘no’ without thinking. After all, presumably these questions are aimed at catching smugglers or criminals of some other type. The questions almost seem redundant for ‘normal’ people.

Let’s examine one of the questions, as I think some of the patterns here are important for business and business analysis more generally….

What does “unattended” mean?

Let’s take the first question (“have you left the bag unattended?”). This question is, upon examination, really quite vague. In fact, I’m pretty sure the actual question airport staff is more specific, but humor me and let’s imagine they ask it in this way.

A first challenge is what the word ‘unattended’ means to one person might be quite different to another. Take the following situations, do you consider them to mean that the baggage has been left ‘unattended’?

You’ve just taken a connecting flight and have had to re-check your bags. Your bags have been handled by baggage handlers, and have been left unattended in the hold of the plane
You traveled to the airport by bus. The bags were in the baggage compartment of the bus and you didn’t have access to them during the three hour bus ride. There were several stops along the way where passenger bags were loaded/unloaded. Anyone could have accessed your bag at those times.
You drove to the airport. It was a long drive so you stopped for gas and a meal. Your car was parked in a car park for over an hour
You traveled as a group in two taxis. Your bag was in the other taxi, accompanied by your friends but not you

It’s tricky, isn’t it? Technically, if you’ve checked your bags into a previous flight, they have been unattended for a period of time. Yet, you’d likely say ‘no’ to this question… because you know that this isn’t a circumstance that actually counts as ‘unattended’. I suppose as travelers we intuitively know what’s being asked and what matters. Or at least we think we do…

After all, if we were to literally interpret the question “have you left your bag unattended at any time?” then there is no way that ‘no’ would be a valid answer. Of course it’s been left unattended at some times… when it’s in the closet not being used!

Beyond Airports: Why Definitions Matter

You probably don’t work in an airport, so might be wondering why I’m obsessing over the wording of a check-in question. This pattern of ambiguity potentially leading to misunderstandings, confusion or (more usually) people making assumptions is rife in organizations and projects too.

Much like the term ‘unattended’ has ambiguity attached, other seemingly ‘obvious’ terms can be problematic. Take the word ‘customer’, it sounds clear, doesn’t it? Perhaps you’ve even written a requirement or user story which articulates what a customer can do. Yet even such a simple-sounding word leaves room for ambiguity. For example:

Does someone have to have already bought something to be considered a ‘customer’? Or does the term ‘customer’ include prospects/people in the buying pipeline too? Or do there need to be two terms, ‘prospect’ and ‘customer’?
If the person paying for a product/service is different from the person using/benefiting from it, which one is the customer? Are they both customers?
Is the term used to mean internal as well as external customers?
Are there different customer types? Does a requirement or story apply to all types or only some types of customer?

Things can get even more complicated than this. Who is the ‘customer’ of the judicial system, the prison service, and so on. It very much depends on who you ask, which is why it is important to actually ask the question!

Definitions Make For Concise Requirements And Stories

This comes back to a key point that is (sadly) often overlooked: definitions matter. A glossary might not be considered a new or exciting artifact, but it can really help ensure people are on the same page. With a clear and shared understanding of key terms, requirements and stories can be more concise.

A small investment in a shared glossary can save lots of time in the long run. Starting early is the most effective way of doing this. And believe me, if you don’t create one, there will come a point in time where you wish you had!

Don’t Just Break the Mold, Shatter It: Rebel Recipes for the Business Analyst Maverick

Written by Paul Benn on November 16, 2023. Posted in Articles.

Photo by Nik on Unsplash

Picture this: You’re sailing on the vast ocean of the business world, navigating the wild waves of change. As a business analyst, you’re the captain of your ship, and your map? It’s pre-skilling – the compass that keeps you not just afloat but steering ahead of the storm. Gone are the days of up-skilling after the fact or re-skilling in the wake of a career hurricane. We’re talking about getting your sea legs “before” the tides turn. Ready to dive in? Let’s set sail!

Why Fit In When You Can Stand Out?

In the high-speed freeway of today’s business, being market fit isn’t just about keeping pace – it’s about setting the pace. As a business analyst, you’re not just in the driver’s seat; you’re also the navigator, the pit crew, and the spark plug all in one. Your adaptability isn’t just a cool party trick; it’s your bread and butter.

Pre-skilling is like having a crystal ball. It’s about harnessing your inner oracle to forecast the skills of tomorrow and training in them today. You don’t just react to change; you dance with it, two steps ahead, making waves rather than riding them.

Talent and Skill Development: The Game’s Changing, Are You?

If you think of your career as a video game, pre-skilling is the cheat code that helps you level up “before” the boss fight. The digital domain is like a game that updates overnight – new rules, new players, new goals. Traditional skill development is playing catch-up, but pre-skilling? It’s got you downloading the updates before they even hit the main server.

Pre-skilling: Not Just Another Buzzword

You see, pre-skilling isn’t a band-aid; it’s a blueprint. It’s not learning to fix a leak; it’s engineering a ship that rides the waves like a pro. It’s the difference between retrofitting your armor mid-battle and showing up with an indestructible suit.

Sailing the Pre-skilling Seas: How to Do It Right

So, you’re convinced pre-skilling is the way to go. But how do you sail these uncharted waters? Here’s your treasure map:

1. Potential Over Past Glory

Forget what you were; what you “can be” is the real gold. Cultivate a mindset that treasures soft skills – the ability to learn, adapt, and bounce back like a superhero.

2. Feedback is Your North Star

Steer by the stars of feedback and career guidance. Have real talks with the crew – managers, mentors, peers – to chart a course that aligns with the future, not just the now.

3. Broaden the Horizon

Your skill set is an ocean – vast and deep. Don’t swim in the kiddie pool. Dive into new knowledge areas, and you’ll find yourself swimming with the dolphins instead of the goldfish.

4. Captain Skills

In the AI-cohabited world, leadership is your sword. Sharpen it. Guide your crew with vision, inspire them with your cause, and lead them through the foggy seas of change.

5. All Hands on Deck for Diversity

Steer clear of the Sirens of sameness. Champion cognitive diversity and inclusive leadership. Different minds on deck make for a robust and innovative ship.

6. Spyglass on Trends

Keep your spyglass fixed on industry winds and currents. Trend analysis isn’t just fancy talk; it’s how you predict the next big wave and ride it like a pro.

7. Market Maps for Skills

Use market analysis to spot uncharted islands of opportunity. Customize your skill set to be the first to plant your flag and claim the land.

8. Bridging Skill Gaps

Perform a gap analysis like you’re checking for leaks. Find where you’re lacking and patch it up before it’s time to face the kraken.

9. Strategic Pre-skilling

Combine all these tools, and you’ve got yourself a pre-skilling compass that points true north. Use it to not just stay on course but to discover new worlds.

Conclusion: Charting Your Course to Market Fitness

So, what’s the final word for our intrepid business analysts navigating the shifting sands of the corporate landscape?

The key takeaway is that the art of pre-skilling is not just a strategy; it’s a dynamic, forward-thinking mindset. It’s about embracing the power of foresight and the excitement of what’s yet to come. In a world that’s racing towards an unknown future, pre-skilling is your secret superpower. It’s the equivalent of giving your career a jetpack, where others might settle for a safety net.

Remember, the sea of business is as merciless as it is magnificent. The winds of change are relentless, and the tides of technology wait for no one. By embracing pre-skilling, you become the captain of your destiny, navigating through the gales with grace and gusto.

To thrive as a market-fit business analyst, you must treat change like it’s your best friend. Why? Because it is! Change is the one constant you can rely on to bring you new opportunities, insights, and paths to personal and professional growth. When you pre-skill, you’re not just keeping pace; you’re setting the pace, transforming from a player to a game-changer in your industry.

By investing in pre-skilling, you’re not just enhancing your resume; you’re forging a professional identity that’s as resilient as it is versatile. This identity becomes your brand, signaling to employers and colleagues alike that you’re not only equipped to handle the challenges of today but also the revolutions of tomorrow.