Tag: Project Management

5 Ways a Good BA/Developer Relationship is Essential for Project Success

Written by Maya Linden on August 31, 2022. Posted in Articles.

Skillful relationship development and management is number one in the toolbox of successful Business Analyst. But one of the most important relationships a BA needs to cultivate for positive project outcomes is that with Developers.

Depending on project management methodology employed, the ease of managing this relationship can differ. For example, an Agile framework can enhance communication between BA and developer, whereas Waterfall could make it more difficult. However, with careful planning and conduct, the following approaches can ensure the BA/Developer relationship is highly functioning and at its most productive under any circumstance.

Provide clear and detailed requirements

To make the Developer relationship ultimately functional, BAs must provide clear and concise requirements to the Developer to prevent potentially project-damaging assumptions.

Concise is the important consideration here, because while requirements must be as complete as possible to make the project run quickly and efficiently, don’t mistake excessive detail and unnecessary documentation for detail. These will have the opposite effect.

To determine strategically what information to provide to the Developer, focus on their points of interest such as data elements and sources. Using your experience from previous projects, you should try to provide information that anticipates and answers the questions the Developer might have during the course of the project.

Get to know the workflow

It goes without saying that to ensure relevant and timely communication with Developers, BAs need a clear understanding of the workflow for each project. But they should also make an effort to understand the corresponding development timeline, processes and tools.

This technical understanding will enable relevant communication of requirements to the Developer in a way that aligns with their established workflow and will be most useful to them for creating an efficient delivery schedule.

Dedicate time to documentation

By providing essential analysis documentation to Developers, BAs can expedite project delivery by reducing potential ambiguity and assumptions regarding requirements and expectations.

At minimum, documents applicable to any project should include detailed data modelling to ensure product delivered meets stakeholder expectations; acceptance criteria to facilitate successful testing and output; and a roles and permissions matrix for all stakeholders to enable efficient development process and analysis.

Explore the unstated

To aid the development process and support a positive Developer relationship, it’s important that BAs bring to light any implicit project requirements and provide these in detail to the Developer.

Project proposals usually include the stakeholder’s explicit requirements, but must be analyzed deeply for insight into what other requirement have not been included but are nevertheless essential for project success.

By developing a 360° outline of all potential requirements or Developers, BAs can usually prevent assumptions and therefore disappointing product output.

Contribute to QA

To build a successful relationship with the Developer, BAs should focus on supporting the Quality Assurance project phase.

During the QA phase, BAs should use their expertise and insider knowledge of business processes and solution expectations to determine potential bugs and defects early. By doing this, they can offer Developers feedback on identified risks often and early to ensure User Acceptance Testing processes are more efficient – and ultimately safeguard against delivery delays and project failure.

Did You Know That a Business Analyst Is as Important in Software Testing as a QA Specialist?

Written by Alex Khomic on August 18, 2022. Posted in Articles.

An IT Business Analyst is a member of a product development team. Such specialists are involved in all stages of the SDLC, from requirements gathering to software launch. They not only connect project teams with customers but also know the peculiarities of products in detail, resolve disputes and advise how this or that software solution should work according to the requirements. They are also an authoritative source of information for QA professionals. Let’s take a closer look at the role of a Business Analyst in software testing.

Primary responsibilities of a Business Analyst on a project

A Business Analyst represents an IT outsourcing company team at the first meeting with a customer and remains the main contact person for product development until the end of a project. This specialist informs developers about the client’s interests and makes it possible for the product owner to give feedback on the software. Business Analysts help to carry out business communication, and any project starts from their work. The main responsibilities of these experts can be briefly described in four theses. A Business Analyst:

Helps businesses to study the market and current offers to learn about competitors’ strengths and weaknesses and thus build the best application. Analyzing market trends, a Business Analyst foresees what will be relevant for users at the time of product release. As a result, the platform will be interesting for the target audience and function properly from the first day of launch.
Advises the client on how to develop a product with minimal investment and maximum ROI in the future. Using the results of market research and relying on the capabilities of the client, they offer a “silver bullet” to solve business problems so that the customer achieves the desired goals at a lower cost.
Prepares documentation for the project which is a kind of “bible” for the development team. Based on it, programmers write code, designers prepare layouts, and testers create test cases. Thanks to the specification, customers track the progress and make sure that the software meets their vision and the project goes according to plan.
Advises the development team on relevant issues. Such an expert knows more about the product being developed than other team members. This fact makes them the main product consultant who will clarify any requirements.

“But what about testing?” you may ask. Let’s figure it out.

What does a Business Analyst have to do with software testing?

As we have mentioned above, an IT Business Analyst prepares the basis for a project and launches the work of all team members. Requirements prepared by this specialist become a guideline for developers, testers, and designers. Business Analysts do not directly test the product, but participate in the following procedures:

Preparation of test documentation. A Business Analyst checks the correctness of test cases, helps to generate test data and suggests an improvement plan.

This specialist signs a test plan if authorized to do so and checks if existing scenarios match user stories.

A Business Analyst prioritizes requirements and features and changes the priority if the conditions on the project change.

Such an expert helps to make sure that the detected incorrect behavior of a system is a defect. QA specialists focus on requirements in their work, but if they do not understand certain points, they turn to Business Analysts to clarify the details, examine bugs, and tell if these are bugs indeed or the intended behavior of the program.

This IT professional resolves disputes between developers and testers. Even if the requirements are written and collected, this does not mean that everyone understands them in the same way. A developer and a tester may see the functionality of a feature in different ways, which can lead to arguments about whether this is a defect or a FAD (feature as design). To resolve the situation, a tester also turns to a Business Analyst. Their resolution is considered decisive.

The more accurate and understandable a Business Analyst describes the requirements for a product, the fewer mistakes developers and testers will make. This means that they will complete the work faster, the functionality will not have to be redone, and the project budget won’t be wasted.

The role of a Business Analyst in testing

An IT Business Analyst is an authoritative member of a development team, whom QA specialists turn to for advice at any stage of testing. This expert knows the functional and non-functional features of the application being created, so their word on the project is the law. A QA specialist seeks advice from a Business Analyst when conducting:

Functional testing. A Business Analyst explains the business logic of the project and points that are incomprehensible to a tester.
Regression testing. Based on critical business functions, a Business Analyst advises which test cases to include in this testing phase.
Usability testing. For a Business Analyst, it is important that the application is as convenient as possible and has demand in the market. This will allow the customer to evaluate the performance of this expert and their foresight. They also recommend to testers how to improve a particular functionality to increase the quality and value of software solutions.
End-to-end testing. To create end-to-end tests, a QA specialist needs to understand an application, its business logic, and user scenarios. In this case, the tester will be able to use the important details for each function: the correct input data, the exact restrictions, the correct sequence of steps, and different ways to call a function.
Acceptance testing. A Business Analyst confirms that the product meets the business requirements.
Beta testing. IT outsourcing company testers are not involved in this type of testing. In this case, real users work with the application. A Business Analyst observes this process, notes what needs to be improved in the product before its release, and makes sure that the application is really valuable.

Conclusion

Thus, a Business Analyst is not just the owner of the requirements on a project or a translator of a customer’s ideas. Any development team needs this expert at every stage of the SDLC, in particular during software testing. Business Analysts are responsible for quality and compliance with requirements, that’s why they participate in many project activities: from the specification of requirements, and approval of test cases to UAT testing control. Only in this case, the planned functions will be correctly implemented, end-users will be satisfied, and the client will receive the desired profit.

Think “Re-use” When Writing Requirements

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

When working on a project or product development initiative, the focus is usually on getting the product ‘over the line’ within a defined timescale. There can be immense pressure to create requirements artifacts quickly, creating just enough to communicate the key business needs to developers and other stakeholders.

This is completely understandable, but it can lead to somewhat of a ‘groundhog day’ like scenario where requirements that are very similar (or even the same) are written multiple times by multiple teams. When the pressure is on, there is less opportunity to think about re-use. Yet requirements re-use, when executed well, can save time in the long run.

Dispelling Myths: “Re-use” doesn’t have to mean copying & pasting

One common misconception is that because no two projects or products are exactly the same, there is no way that any requirements can be reused. However, re-use doesn’t have to mean literally copying & pasting—sometimes it can mean that a set of requirements are used as a starting point to build from.

Imagine that you write a set of non-functional requirements for a customer-facing web application. If, in the future, another team elsewhere in the organization needs a web app, then surely the NFRs that you’ve written would be a useful inspiration? The requirements might only be 80% similar, but the existing artifact means that there’s no need to start from a blank page. Of course, this doesn’t remove the need to ask the right questions and engage the right stakeholders, but having an existing document to build from can save time.

In fact, there can be a benefit in having a “standard” set of NFRs for particular types of systems. Many organizations have their information security policies defined, their brand guidelines defined and so forth. Why not bring all of these policies together, adding other types of NFR, to create a corporate standard? This will likely vary by context, but certain patterns will be relevant for particular situations. Clearly, building or maintaining an internal application is likely to attract different types of requirements to one that is exposed to the outside world. This is just one example.

High level artifacts

It is also worth keeping high level artifacts that show the broad scope of what a particular system or product does. Context diagrams typically show the adjacent systems/actors that are relevant for a particular work area, and the high level data flow. One day, someone is going to want to replace a key IT system… having an up-to-date context model would provide a massive head start. The same is true of business process models. If a new process is implemented, this is an opportunity to identify a process owner. The process owner is typically responsible for keeping the process model up-to-date. Imagine having a central repository with all (or even some) of the organization’s processes stored. This cuts down the effort of ‘as is’ modeling. (I say ‘cuts down’ and not ‘eliminates’, because it’s usually still necessary to see how people are actually undertaking the work, which may or may not be exactly as it is documented!)

Teams and Individuals

Another way artifacts can be reused is as examples or exemplars. When a new BA joins the team, they will often need guidance over ‘how we do requirements here’. Of course, experienced practitioners will bring their own views, but it is useful to have an expectation of what ‘good’ looks like. Too often organizations simply have templates or written standards. These are useful, but alone they are rarely enough… templates or standards with examples are far more useful. This doesn’t just apply to written documents, it can apply to models and requirements stored in repositories too.

These examples can also be used when a BA needs to show a stakeholder examples of business analysis work. Imagine trying to convince a skeptical stakeholder to engage with the BA team. Having a successful case study to show them, along with some fragments of requirements artefacts, prototypes and a working solution to show them might just help set the context. Stakeholder testimonials from the project will help even more.

But There’s No Time!

I know, I know, at this point you’re probably thinking “we’d love to do that, but there’s no time!”. I get it, deadlines are harsh and nobody wants to work even longer hours. There might not be time within the project, but there might be time afterwards or during natural periods of downtime if you are lucky enough to have some of those. Taking time to spruce up requirements artifacts, putting them somewhere central, and cataloging them so they can be found will save time in the long run. It is a short term effort for long term gain.

If you are a BA manager, you might consider building in an ‘air gap’ between project assignments for individual BAs to wrap-up their work and consider re-use (amongst other things). In many ways, this is building a sustained repository of knowledge for the whole team… and isn’t that an effort worth pursuing?

Analysis Efficiencies: Turning The Mirror On Ourselves

Written by Adrian Reed on June 23, 2022. Posted in Articles.

As analysts, typically we’ll spend a lot of time examining and critiquing the processes of other departments. We might be looking for ways to make an operational process slicker, quicker and ‘better’, or we might be looking to solve particular problems. There are a whole set of elicitation, problem analysis and process analysis techniques in our toolkit that help us do this. Yet how often do we turn these tools in on ourselves to examine our own practices to see if there are ways that we can improve? As practitioners of change, surely we should be looking to continually improve ourselves too?

I suspect we all intuitively do this, at least to a degree, but I wonder if it’s an area where there’s room for improvement. I’ve included some examples to whet your appetite below:

Deciding How To Decide: Have you ever got to an approval gateway in a predictive (waterfall-type) project and it’s unclear who needs to make the approval? Or the approver shirks responsibility? This can manifest differently on adaptive (agile/evolutionary) initiatives, for example with wrangling over the ‘definition of done’ with different stakeholders having different (and unresolved) perspectives. These things can fester if unresolved, perhaps stakeholders concede in the short term and sign on the dotted line, but resentment builds and bubbles up, only to explode out later at the most inconvenient time.

This creates friction and drama that takes time to resolve, and when it comes to organizational change, time is money. It’s therefore beneficial to spend a little bit of time up front agreeing how these types of decisions will be made. This sounds so obvious doesn’t it? Yet, so often in the blind rush to “just get going” it isn’t discussed… and it is only as the decision emerges is the omission spotted. Practical tools such as the RACI matrix can be extremely useful here.

Planning the Requirements Architecture: When BABOK® v3 was released back in 2015, one of many significant additions was a more explicit recognition of requirements architecture. If you have ever found yourself mid-project with a whole set of useful, but disparate requirements artifacts (“These process models are great. But how on earth do they relate to those user journeys, these scenarios and those wireframes?!) you’ll know what I mean.

Taking time up front to quickly and roughly sketch out how it’s anticipated that the requirements will fit together helps avoid this. Of course, things change, as requirements emerge, new types of artifacts suddenly become relevant (“Ah, so statuses are important… I think I’ll include a state transition model…”), however having a starting point to deviate from when appropriate is better than fumbling around in the fog.

On a legislative project, you might write a quick problem statement to act as a high-level goal/outcome, and define some critical success factors/key performance indicators which will act as desired outcomes. These will all link to the organization being compliant with a piece of legislation, that’s another (external) artifact, but one which some rules can be derived from. Those rules will include internal decisions about how the legislation is interpreted; so those probably need to be captured too. Those rules might be automated or orchestrated via processes, and there might be steps in a process which will be automated via some detailed functional solution requirements. You can see how these different concepts relate to each other here; and of course there will be other types of artifacts too. The point is that creating a quick sketch showing how the concepts map together before creating them will prevent artifacts from being created that don’t clearly relate to each other.

Planning How To Store/Manage Requirements Artefacts: If you’re lucky, you’ll have some form of requirements (or story) management tool. If that’s the case, does everyone actually know how to use it? Is there a common agreement around how things like priorities/statuses and other metadata will be used? If not, will this create noise and friction as the initiative progresses? If so, a short discussion up-front is likely to yield significant benefit.

If you are using documents and a shared document repository (e.g. word processing tools, drawing tools, spreadsheets etc.), decide things like naming conventions and version control conventions up front. It can be very confusing when someone in the team is using a file naming convention that uses “v0.1”, “v0.2” then “v1.0” when it’s signed off, when another person is using “FILENAME v1.0 (Updated) (Second Updates) (Final) (Really Final This Time) (Updated Again).docx”

Plan For The Analyst And Stakeholder Of Tomorrow: Stuff you’re creating today will be useful for the analysts and stakeholders of tomorrow. That process model you’ve created? If it’s detailed enough, I bet the training team would love to use it, and the operations team might too. It might be the catalyst to the creation of a single, unified process repository (if that doesn’t already exist in your organization).

Those performance non-functional requirements for your customer-facing website? You know, the ones that were like pulling teeth to elicit, that required benchmarking and speaking to the technical folk? They might be a useful baseline and starting point for others producing customer-facing web applications within your organization.

As we create artifacts, we ought to be thinking not just about how they can be used today, but how they might be used tomorrow and how we can ensure they will be found. This is a much bigger, organizational, question—however it’s one of the many areas where BAs can nudge the agenda. By creating common pools of knowledge, and by encouraging information sharing we open up channels for these types of artifacts to flow. This has the advantage that information flows in both directions and also that there will be a wider range of documents available at the start of projects too.

Of course, these are only four suggestions, there will be many more. The key is that we shouldn’t rest on our laurels; as BAs we should be looking to hone our craft and improve the efficiency and effectiveness as much as we can. This involves not just “speeding to get the job done”, but also thinking about the stakeholders of tomorrow!

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