Tag: Business Analysis

Beyond the Finish Line: Understanding the Art of Value Enablement

Written by Adrian Reed on December 27, 2023. Posted in Articles.

We recently needed some repair work done to the roof of our house, so called some local roofing firms. Understandably, roofers don’t always answer their phones immediately (I guess they are often out on site working), so we left voicemails for three different roofers.

Out of the voicemails we left, only two of the roofers replied. Both came round, inspected the roof, and explained what needed to be done. They both said they had availability and would send over a quote showing how much the work would cost. However, only one of the roofers actually sent a quote. We accepted the quote and I’m pleased to say that the work is now complete. But this got me thinking about business, business analysis, and value-enablement more generally.

Close, But Stopped Short

Let’s examine the approaches that the different roofers took. The first one didn’t reply. We might argue that this is bad customer service, but if they knew they were busy and had no shortage of business, then not replying might be an acceptable thing to do. It might not be a good long-term approach, but it doesn’t waste any of my time or their time. So while I might have preferred them to drop over a quick reply, I can understand why they didn’t.

The roofer who I really don’t understand is the one who came out, inspected the roof, but didn’t follow up with an estimate. They were so close to actually getting the work, but they failed because they didn’t carry out the final task. They’d spent time (and gas) driving out to see the roof, only to implicitly ‘give up’ by not following up. I found this really puzzling!

When Is Value Enabled?

This led me to think about value in a broader context, and I think it has some interesting parallels with business analysis. The roofer did all the work to potentially enable some value for him (payment) and for me (a fixed roof), but stopped just before a crucial moment.

In a project or product context, usually we are building (or changing) something with the purpose of enabling value for a range of stakeholders. The value that is enabled may vary for each stakeholder group. A retail bank releasing an app might provide convenience for its customers, while also saving money (and increasing profit) for its shareholders. For the app to be a success, it needs to balance the different perspectives on value. If it’s inconvenient, or hard to use, it’ll backfire—it might actually increase the number of times people call the call center, meaning operational costs increase. Knowing what different groups value is important so that this balance can be struck.

Yet as well as knowing what value can be enabled, it’s important to know when that happens and what the precursors are. Imagine a bank released a self-service banking app but didn’t advertise it to its customers. Sure, some early adopters might find it in the app store, but there would be a range of people who would use it if they knew about it that probably aren’t actively looking for it. Delivering the app without a communications and engagement plan alongside might end up being similar to the roofer who didn’t send a quote… it stops just short of the line for value enablement.

Finding The Finish Line

It is worth fostering discussions over what needs to happen not just for a product or project to be delivered, but what needs to happen for value to be enabled. It is too easy to stop just short of the finish line and declare success prematurely. “On time” and “on budget” are important aspects, but “on strategy” and “on benefit” are things that make a long-term difference. In the fog of urgency, it’s important that we don’t lose sight of these.

As James Clear comments in his book Atomic Habits, there’s an old saying that “the last mile is the least crowded”. Perhaps that’s just as true in a project and product context, and by focusing on the last mile and cultivating conversations about value we can help achieve better results for our stakeholders and communities. And surely that’s worthwhile?

Baking Success: Unveiling the Sweet Similarities Between a Small Baking Business and a Business Analyst’s Role

Written by Christelle Govender on December 20, 2023. Posted in Articles.

Embarking on my journey as a baker just under two years ago, I have joyfully crafted birthday cakes, engagement cakes, baby shower confections, and more. Recently, I faced a culinary challenge that pushed my skills to new heights. This cake wasn’t just another creation; it was a test of my abilities, filled with many “firsts” that transformed my approach to baking. From applying a white chocolate ganache coat to mastering a full fondant covering, I encountered unexpected hurdles that required constant adaptation.

As I navigated the complexities of this ambitious project, I realized that I was implementing a form of agility in motion. Much like a Business Analyst (BA) adapts to evolving project requirements, I found myself breaking down the cake-making process into smaller, manageable increments. Baking the layers two days in advance and freezing them, preparing the frosting a day ahead, and meticulously crafting fondant toppers became a harmonious dance of preparation and adaptation.

This experience illuminated the surprising parallels between my role as a baker and the responsibilities of a Business Analyst. In both worlds, adaptability is the key ingredient for success, allowing for the seamless integration of unexpected challenges into the creative process. Let’s delve into the sweet symphony of similarities between managing a small baking business and excelling as a Business Analyst.

Adaptability is the Key Ingredient:

In the world of baking and business analysis, adaptability is the secret sauce that leads to success. Just as a baker adjusts a recipe based on available ingredients or customer preferences, a BA must be flexible in adapting to changing project requirements, client expectations, and market dynamics. Both roles demand a skillful balance between structure and spontaneity, ensuring the final product meets or exceeds expectations.

Customer-Centric Approach:

In both professions, understanding and satisfying the customer’s needs are paramount. Bakers pay close attention to customer preferences, dietary restrictions, and flavor profiles. Similarly, a BA delves deep into understanding the client’s business requirements, ensuring that the solutions provided align with the client’s goals. Both roles involve effective communication and active listening to create a product or solution that leaves the customer delighted.

Requirements Gathering as a Recipe:

Much like developing a baking recipe, a Business Analyst must meticulously gather and document requirements. In baking, this involves understanding the desired flavour, texture, and appearance of the final product. In the business world, requirements gathering entails collaborating with stakeholders to determine the functionalities, features, and constraints of a project. Both processes require attention to detail, precision, and a knack for turning abstract ideas into concrete plans.

Project Management:

Running a small baking business involves managing resources, timelines, and deliverables – much like a BA managing a project. Both roles require effective project management skills to ensure that everything runs smoothly, from planning and preparation to execution and delivery. Time management, coordination, and the ability to troubleshoot issues are crucial aspects that bridge the gap between these seemingly diverse professions.

Continuous Improvement:

In the dynamic worlds of baking and business analysis, there is always room for improvement. Bakers experiment with new recipes, techniques, and ingredients to stay ahead of trends and meet evolving customer tastes. Similarly, BAs must stay informed about industry best practices, emerging technologies, and changing market trends to provide innovative and effective solutions.

Understanding Global Trends and Market Dynamics:

In the ever-evolving landscapes of both baking and business analysis, awareness of global trends is paramount. For a baker, staying attuned to culinary trends such as the rise of veganism or the demand for gluten-free options is crucial. Just as a baker adapts recipes to cater to changing dietary preferences, a Business Analyst must be cognizant of market trends and technological advancements. Incorporating global trends into business strategies ensures relevance and competitiveness. The ability to anticipate shifts in consumer preferences aligns closely with a BA’s role in recognizing emerging market demands, enabling both to proactively adjust their approaches for sustained success.

Risk Management:

The concept of risk is inherent in both the realms of baking and business analysis. In the baking business, the risk might involve experimenting with a new flavor combination or trying out an innovative baking technique. Similarly, in business analysis, the risks could range from technological uncertainties to unforeseen changes in project scope. Both roles require a keen sense of risk management – identifying potential challenges, developing contingency plans, and mitigating risks to ensure a successful outcome. Whether it’s predicting how a cake batter will rise or foreseeing potential project obstacles, effective risk management is the insurance policy for success in both fields.

Visual Thinking:

In the world of baking, the visual appeal is as important as the taste. Creating aesthetically pleasing cakes involves a form of visual thinking, where bakers conceptualize designs, color schemes, and decorations. Similarly, Business Analysts employ visual thinking when crafting process flowcharts, diagrams, and user interface designs. Both professions rely on the ability to translate abstract ideas into tangible visual representations that effectively communicate complex concepts. Whether it’s envisioning an elaborate cake decoration or designing a user-friendly interface, visual thinking is a powerful tool that enhances creativity and clarity in both baking and business analysis.

Conclusion:

Despite appearing dissimilar at first glance, both industries align on fundamental concepts such as versatility, prioritizing customers’ needs, meticulousness, and a steadfast dedication towards enhancing one’s performance constantly.

Just as a baker meticulously crafts a cake, considering evolving culinary trends and customer preferences, a Business Analyst navigates the complex landscape of project requirements, global market dynamics, and technological shifts. The parallels are striking – both professions demand a delicate balance between structure and spontaneity, transforming challenges into opportunities and setbacks into stepping stones.

The recipe for success transcends the boundaries of specific industries. The amalgamation of these skills – adaptability, customer-centricity, attention to detail, continuous improvement, global awareness, risk management, and visual thinking – creates a masterful blend that resonates across baking and business analysis. Whether you’re sculpting a delectable cake or orchestrating a cutting-edge business solution, the essence of success lies in skilfully blending the right ingredients to create a masterpiece that not only delights but endures in the ever-changing landscapes of taste and technology.

Five Ways BAs and Inventory Managers Can Make Jobsites More Profitable, Together

Written by Lucas Marshall on December 13, 2023. Posted in Articles.

Business analysis is a critical skillset and operational imperative companies need to prioritize as they look to be profitable and understand how they can make measurable improvements as they scale. This fact is not lost on corporations, either—for example, 72% of manufacturing executives said that they considered advanced analytics to be important, according to a report by BCG.

The construction sector, meanwhile, consistently finds itself in a precarious state in terms of profitability no thanks to employment challenges, influx materials pricing, and the disjointed nature of the construction ecosystem. For example, experts estimate job growth in the construction industry is projected to be at a stagnant 1.1% for ten years (Data USA via Finances Online). Underperformance, Autodesk concludes, is an industry-wide norm with 72% of firms saying projects have taken longer than anticipated—and 44% of firms putting longer completion times into their bids, according to data from Associated General Contractors of America (AGC). In fact, merely 25% of projects came within 10% of their original deadlines, a KPMG report found.

The World Economic Forum (via Autodesk) estimated that a 1% reduction in construction costs could save society $100 billion globally. As the construction sector ecosystem looks to execute projects in a quickly changing environment, these existential challenges warrant organizational changes to better negotiate the trials and tribulations at hand.

We also have to consider the average construction company’s costs to better contextualize these challenges and opportunities. If we assume that the average cost of a construction project is comprised of overhead, materials, tools and equipment, and labor, then focusing on what you can control will help move the needle toward greater profitability. For example, while you might not be able to affect the cost of materials, you can negotiate work to accommodate the resourcing you currently have, and you can make plans for improving internal processes to drive greater efficiency.

I’ve previously written about how project managers in the construction industry should embrace change management, as well as how the industry might adopt big tech’s displaced software engineers to address industry digitization problems, and how the construction industry looking to adopt lean management principles may borrow some of the similar practices from agile software project management.

Studies show that business analysts are more prone to support collaboration in agile projects.

With this in mind, in this article, I look to unpack two roles—the Business Analyst and the Inventory Manager—and discuss how a collaboration matrix between these roles can help construction companies work leaner, more efficiently, and drive greater profitability over time.

The Role of the Business Analyst & Why BAs May Be a Critical Construction Industry Hire

Considering construction’s profitability concerns, the role of a business analyst (BA) from the corporate environment is one that construction companies may look to fast-track.

Responsible for “bridging the gap between IT and the business using data analytics to assess processes, determine requirements, and deliver data-driven recommendations and reports to executives and stakeholders,” a BA in a construction company setting can “offer valuable insights to enhance financial planning and resource allocation,” reads the job description for a Senior Construction Business Intelligence Data Analyst role at CBRE Group, a global commercial real estate company, which was available at the time of writing this article.

Consider CBRE’s job posting for some of the job-specific functions a Business Analyst in the construction industry may entail:

Applying advanced analytical techniques to conduct prescriptive, diagnostic, descriptive, and predictive data analysis on diverse construction-related data, incorporating data from Quickbase, eBuilder, SAP, and Google Sheets.
Developing dashboards, meticulously maintained [… that] provide real-time insights into construction project data while ensuring these dashboards are user-friendly, intuitive, and deliver vital information to project collaborators (e.g., stakeholders).
Generating regular and ad-hoc reports for the leadership team, highlighting essential performance indicators, project status, and emerging trends, while translating sophisticated data into practical, actionable insights, incorporating earned value measurement concepts to evaluate project performance.
Providing meaningful support for annual capital planning by conducting comprehensive analysis of historical data, project costs, and resource allocation, offering valuable insights to enhance financial planning and resource allocation.
Developing and maintaining strategic forecasts for construction projects, demonstrating data analytics to identify trends and make informed predictions about future outcomes, incorporating earned value measurement techniques to assess project performance and forecast project completion accurately.
Providing data-driven insights that support critical business decisions, helping to improve operational efficiency and profitability.

Construction forecasting is one critical business process a business analyst may help owners more accurately predict through advanced analytics, historical trends, and advanced technology management (e.g., artificial intelligence).

When they collaborate with other critical business functions (e.g., inventory management, discussed next), greater outcomes may become more easily within reach.

The Role of the Inventory Manager in Construction Projects

An inventory manager in the construction industry (aka: tool crib manager, tool room manager, asset manager, equipment manager, etc.) is responsible for the strategic direction, allocation, storage, and flow of all the physical assets needed to perform construction work—e.g., building materials, tools, vehicles, and equipment.

An inventory manager assures jobsite materials, tools, and equipment arrive on jobsites as they’re needed, are in working order (e.g., tools are properly serviced, materials are not damaged, etc.), and are returned or rerouted across projects as needed to prevent slippage and excess asset turnover.

With an inventory manager at the helm of the construction supply chain, companies might realistically see a 10-12% reduction in labor cost originating from avoiding non-productive idle time or downtime—that is to say, when materials are where they’re needed, manpower doesn’t need to search for them or idly wait for their arrival.

How BAs and IMs Can Work Collaboratively to Drive Better Profitability Outcomes

Now that we’ve discussed what a Business Analyst role may look like in the construction sector, as well as the role of an inventory manager in the same sector, how might these cross-functional teammates work together to drive better profitability outcomes?

Here are five ways:

1. Procurement Strategies

A business analyst, tied into company forecasting, can work closely with inventory managers to establish objectives for procurement strategies and capital investment as well as determine needs based on ongoing inflight projects and company annual goals.

Together, they might reasonably achieve strategic themes when approaching inventory-related financial commitments and implement cost-saving measures, including:

Appropriate Safety Stock Purchasing – Together, a business analyst and inventory manager can cross-pollinate company-specific analytics related to equipment purchasing, historical trends of project needs, and existing commitments in order to reasonably define policies for shelving inventory and planning for needs (i.e., how much to buy, when). Such a collaboration can help prevent excessive inventory procurement that would otherwise lead to unnecessarily rising overhead, while it can also help facilitate proper procurement to prevent inventory stockouts. What’s more, using advanced analytics via artificial intelligence can help predict future needs.
Proactive Inventory Audits to prevent needless spending over project lifecycles as well as to provide better long-term inventory management outcomes.
Deploying cost-centric, advanced inventory management strategies like just-in-time inventory. This method prioritizes strategic, lean operations in order to deploy only what’s needed when it’s needed, preventing excessive inventory procurement (and like above, preventing unnecessarily rising overhead). The method also requires inventory managers to proactively intervene to prevent jobsite hording, hence why inventory tracking (e.g., Bluetooth tags, GPS trackers, etc.) is critical.
Performing XYZ analysis to calculate: fixed demand (X), fluctuating demand (Y), uncertain demand (Z). Determining these inputs can help inventory managers more effectively achieve more positive outcomes by ranking the frequency and predictability of demand for items over time.

2. Job Costing

In addition to financial forecasts and reporting, business analysts can work with inventory managers to adopt a job costing solution. Job costing in construction refers to the proactive process and steps taken to track the associated costs and revenue of a given project throughout its lifecycle.

The process can be used in inventory management, where inventory managers can apply rental rates (daily, weekly) to equipment that is deployed to the field (either individual or bulk inventory that’s been kitted/bundled and sent at once). Job costing software then calculates the cost accrued for each day (or week) those items are in the field.

This process can help:

Inventory managers better account and monetize on the equipment they send to their network of jobsites.
Financially incentivize borrowers to return equipment in a timely manner, reducing the “time on site” of a particular piece of inventory as well as the need for additional safety stock, unnecessary rerouting of equipment from other jobsites, etc.
Provide additional revenue streams to construction businesses.

3. Reporting

In addition to the business analytics dashboards that a construction business analyst might build for a business owner as discussed in the above-mentioned job description, inventory managers can work hand-in-hand with business analysts to provide additional reporting opportunities, including:

Tool Management Reports – reports about ongoing usage of inventory (e.g., average “days on site,” as we discussed above, to help make improvements on how inventory is used in the future; service-related alerts, to help proactively take charge of equipment maintenance, improve longevity, and decrease overhead; inventory assigned by jobsite or person, to increase accountability; etc.)
Asset-specific reports, such as utilization on some smart power tools, which can help diagnose problems before a jobsite-halting breakdown occurs as well as provide quality assurance to customers and inspectors that installations were performed to specification.

4. Interoperability

Construction interoperability is the practice whereby construction systems (e.g., software platforms, apps, processes) interact with each other and the extent to which they possess the ability to operate seamlessly and share information between each other.

A KPMG report revealed that only 16% of executives surveyed say their organizations have fully integrated systems and tools—a serious problem when we consider how fragmented the construction ecosystem is. Consider, too, that only 36% of firms have implemented a process for identifying bad data and repairing it (Autodesk/FMI report).

Together, inventory managers and business analysts can start to build system interoperability that can both provide a single source of truth and prevent cost driving incidents like rework (e.g., from the same Autodesk/FMI report, 14% of all construction rework may have been caused by bad data, creating $88.69 billion in avoidable rework globally).

Possible interoperable systems include:

Connecting data flow between a project management system (e.g., Procore, Autodesk Construction Cloud, Contractor Foreman, Houzz Pro) and architecture, design, and civil engineering (e.g., Revit, AutoCAD, SketchUp, Bluebeam, Autodesk BIM 360, Civil 3D, ArcGIS, Bentley STAAD, etc.)
Connecting data flow between inventory management systems and mission-critical systems (e.g., project management, design, etc.)
Building digital twins (e.g., asset twins, component twins, system twins, process twins) to provide holistic views of cross-network activities, predictive analytics, and real-time data and simulations to aid in decision-making.

5. Planning for Addressing Technical Debt

Technical debt is a phenomenon whereby dependencies one introduces when deploying new software and hardware solutions lead to operational slowdown.

A colleague and I have outlined five ways construction companies can prevent technical debt. A business analyst and/or construction technologist may work hand in hand with an inventory manager to prevent technical debt relative to construction operations from piling up – e.g.,

They may work with IT to deploy cloud-based systems (i.e., real-time collaboration).
They’ll deploy inventory tracking hardware to ensure real-time inventory activity is recorded.
They’ll ensure mobile apps integrate with construction ERPs.
They may work with the cybersecurity team to ensure proper MDM deployment and data security best practices relative to inventory.

Bottom Line

The construction industry faces some dire operational challenges.

While construction companies might not be able to affect the cost of materials, they can focus on factors they can control—e.g., improving internal processes, empowering the team to work more seamlessly together.

When working collaboratively, business analysts and inventory managers can help companies operate more agilely, more strategically focused, and they can help achieve greater profitability over time.

Work like a Surgeon

Written by Nurani Easwaran on December 7, 2023. Posted in Articles.

There is an old joke about a surgeon and a mechanic that goes like this:.

A mechanic was removing an engine part from the motor of a car when he spotted a world-famous heart surgeon in his shop. The heart surgeon was waiting for the service manager to come take a look at his car. The mechanic shouted across the garage, “Hey Doc, can I ask you a question?” The famous surgeon, a bit surprised, walked over to the mechanic working on the car.

The mechanic straightened up, wiped his hands on a rag, and asked, “So, Doc, look at this engine. I can also open it up, take the valves out, fix them, and put in new parts, and when I finish, this will work just like a new one. So how come I get a pittance and you get the big money when you and I are doing basically the same work?” The surgeon paused, smiled, leaned over, and whispered to the mechanic, “Try doing it while it’s running.”

The world in which a business analyst operates is quite like the surgical world, in the sense that a BA works with a live or running organisation and needs to make the necessary changes or improvements to the company without shutting down the currently running processes, delivering the required change while reducing impact to the minimum.

We will extend this analogy a little further from the beginning of the process (the patient comes in for consultation) until its logical conclusion (the patient goes home with the issue fixed) and see what observations we can gain from the medical world. We will also use this journey to look at the toolset available to a business analyst and determine which tool would work the best for which stage of the process.

Let us follow the example of a hypothetical heart surgeon. A patient complaining of chest pain is referred to him by a local GP. The surgeon reviews the medical exam tests conducted by the GP, forms some initial conclusions about the issue, and validates the same through further diagnosis of the patient. Based on the diagnosis and the testing, the surgeon determines that the heart is not in a good condition and that there is a high chance of heart failure. The surgeon advises that heart surgery is required to resolve his condition.

This carries some risk; however, avoidance of the surgery carries a greater risk and is more likely to result in cardiac arrest. He directs the patient to the hospital admin team to get an idea of the costs involved. The hospital admin team provides the patient with all the details, including the overall cost, including the pre-operation treatment, cost of operation, cost of recovery procedures, and timelines of each stage, so that the patient has a good idea of when the operation procedure will start, how long the entire process will take from end to end, and how much it will cost.

The patient agrees with the cost and the timelines and makes the arrangement to pay the funds to the hospital by the agreed date. The surgeon proceeds with the operation. The operation is successfully completed on time, and the patient is discharged with regular follow-ups scheduled.

Now, let us consider a parallel example in the software sector, i.e., a medium-sized software company. The company has noticed a steady decrease in profits along with an increase in customer complaints and wants to fix this issue. The company engages a reputed consultancy for this.

The BA from the consulting team arrives at the company and conducts a detailed study of the current state and the reported complaints. Through a series of discussions with the company members and interviews, the BA identifies all the key parties involved in the processes and complaints. The BA organises a series of workshops with the company representatives and uses several problem-solving techniques, such as the 5 Whys, root cause analysis, the fishbone diagram, and flowcharting of the current process, to get to the bottom of the issue.

The BA ensures that all the relevant parties understand the question by providing them with clear objectives for the workshops and what is expected of them. During the workshop, the BA also ensures that all the members get an opportunity to express their views, so that the findings are as unbiased as possible.

After this process, the BA gets a good understanding of the current state and the main causes of the issues that the company is facing. It appears that the existing software used by the company is quite old. not in line with the current needs, resulting in inefficient and time-consuming processing. There are also a few legacy processes being carried out, with some steps that are no longer relevant but are still being carried out as the staff have always worked that way.

This is resulting in a poor customer experience, with a corresponding decrease in sales and an increase in customer complaints.

These series of workshops have helped the BA and the senior management of the company get a clear understanding of the current state and the main causes of the issues being faced by the company. To take the next steps, the BA also needs to get a good understanding of the future state, i.e., what the company aims to achieve as part of its short- and long-term objectives. To do this, the BA requests that the company provide its vision, goals, and the approach or strategy decided to achieve these goals. Some of this may be readily available in the company documents but may require further discussion with senior stakeholders to clearly flesh it out so that there is no misunderstanding.

For example, the company may have planned, say, a 20 percent increase in market share, but may not have thought through or clearly spelled out all the associated elements, say, an increasing rate of production, the addition of new machinery or employees, the setup of further logistics, getting additional funding, etc. The BA helps the company work through all the dependencies and impacts and create a comprehensive future state model.

The company now has a good understanding of the as-is, or current state, and the to-be, or future state. The BA now organises another set of workshops involving all the key participants to get a clear understanding of what needs to be done to move from the current state to the future state; in other words, the BA is gathering and eliciting the requirements. During this process, the BA ensures that all the identified problems and issues and the vision of the future state are clearly understood by all the participants. This helps to ensure that the requirements are in line with the needs of the company.

Based on the feedback received from the various members of the company and their understanding of what is available in the market, the BA recommends a set of options, including some quick wins through process changes and long-term solutions such as upgrading the software or replacing it with a more efficient one. The BA clearly highlights to the senior management of the company the risks associated with staying as is and the costs, benefits, and risks of the proposed solution options. The BA also supports the company with the change impact analysis process, i.e., how the changes would impact each of the company staff involved in the current process and what can be done to ensure a smoother transition.

Once the BA gets agreement from the key stakeholders on which solution or solutions they would like to progress, the larger team, including the project managers, system architects, IT consultants, testers, and other change management personnel, is brought together along with the key members of the company, and the project is initiated. The BA carefully monitors the requirements through the various stages of the development process using a requirement traceability matrix to ensure that there is no dropping of key requirements or addition of wants based on the personal desires of some stakeholders.

The BA also ensures that the company representatives are kept well informed about the progress of the project and that there is proper end-to-end, two-way communication. This ensures that the project is successfully delivered with minimal post-project impacts.

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.