The Best Development Styles for Preventing Stakeholder Misalignment

best-development-methods

Traditional discovery methods don’t do enough to overcome the risks of stakeholder misalignment.

The best development styles are context – and behavior-based development philosophies that create shared understanding between developers and product owners.

Every business is unique. Even companies operating in the same industry have different operational needs. While this isn’t a problem by itself, it does make working with technology partners more complicated.

There’s often a disconnect between developers and other stakeholders. Developers have to understand exactly what’s needed before they can build it, and getting to that point requires domain-specific knowledge they can only get from their partner.

This is where the breakdown happens. Stakeholders come to the table with different ideas about what the product should look like and how it should work.

When a developer doesn’t make a point of reconciling these misaligned expectations, it can result in budget overruns, damaged reputations, and even project failure.

Traditional discovery methods don’t do enough to overcome the barriers in understanding, though.

Instead, context – and behavior-based development philosophies should take precedence.

The Problem with Misaligned Expectations

Working around misunderstandings might sound like a simple annoyance, but it has wider consequences for developers.

Features that don’t do what the client needs have to be reworked, and new ones get added last minute. Such a stressful experience damages the client-developer relationship.

Clients are less likely to use the same company again, and the developer may even have trouble winning new contracts.

The consequences go beyond budget overruns and damaged reputations. In 40% of bug tickets developers find that the documentation isn’t clear enough to help resolve the issue.

That adds to the time – and expense – of maintenance.

Contextual Development Philosophies

A well-designed development workflow helps get all stakeholders on the same page. It enables developers to hit requirements better, assess performance more accurately, and produce solid documentation that results in more efficient maintenance. Here are some of the most effective methods in use today:

Example Mapping

Example mapping is a method of guiding a conversation to create a shared understanding among stakeholders.

It’s also known as “Three Amigos sessions”, which refers to the primary perspectives used to examine an increment of work before, during, and after development:

  • Business: What problem are we trying to solve?
  • Development: How might we build a solution to solve that problem?
  • Testing: What could possibly happen and how would we handle that?

Three Amigos can be used to write acceptance tests before implementing the corresponding functionality.

Acceptance Test Driven Development (ATDD)

ATDD emphasizes communication between testers, developers, and product owners, bringing the product owner into the test design process before any coding is done.

Tests are phrased in business-specific terms instead of engineer jargon. Plain-speech feedback comes quickly and is easy to incorporate going forward.

This focuses development on actual business goals. It also facilitates clear communication, so everyone understands what is happening, what should be happening, and where things are going wrong.

ATDD is a contextual approach to exploring software requirements. Stakeholders suggest scenarios of how the software will be used, then use those to define requirements and design functional tests.

The process sometimes even uncovers stakeholders who were missing from the process.

Having realistic examples rather than technical abstracts improves communication between clients and developers.

Behavior-Driven Development (BDD)

Under this evolution of Test-Driven Development (TDD), software is built incrementally according to a user story.

Developers create features and adjust design specifically in response to real-world behavior and feedback. The process is dynamic and responsive:

  • A product owner explains part of the process.
  • Developers write a corresponding feature.
  • Testers check whether the feature supports the user story.

BDD uses a structured language called Gherkin to create explicit, easy-to-understand requirements which can be read using Cucumber, a test automation tool.

Here are some of the most common Gherkin keywords and how they’re used in context:

  • Feature describes the feature being tested.
    • “An error message alerting users who make mistakes on the contact form.”
  • Scenario is putting the behavior being described in context.
    • “A user is filling in the contact form.”
  • Given sets the beginning state of the scenario.
    • “If the user enters letters into the phone number space”
  • When describes an action the user takes.
    • “When the user hits send”
  • Then details the testable outcome.
    • “The form reloads with the invalid entry outlined in red and an error message explaining how to correct it.”

There are about ten keywords in all with other uses. (For example, “and” can be used to expand any other other operators.)

The most important thing, though, is that BDD and Gherkin acceptance tests guide stakeholders in choosing where to start development, deciding how to test, and understanding why tests fail.

Final Thoughts

Good communication is the antidote for nearly all major problems that can derail projects.

It follows, then, that the best development philosophies for enterprise software development revolve around improving communication and understanding among stakeholders.

Taking the time to prevent misalignment from the start leads to more productive development and a higher quality final product.

At Concepta, we measure our success by the success of our clients. That’s why we use contextual development methods to be sure our products support specific business goals. Set up a complimentary appointment with one of our development team to find out what we can do for you!

Request a Consultation

How to Define Stakeholders for Your Software Development Project

Stakeholders

A good discovery process is critical to software development. The requirements generated here set the stage for the entire project, laying the groundwork for success or failure.

Involving all stakeholders from the beginning is the single most impactful step developers can take- but identifying those stakeholders isn’t always easy.

Companies who rush through this phase might overlook a group whose support they need down the road. That’s why defining the stakeholders should be a deliberate process during the early stages of discovery.

What Do Stakeholders Do?

The term “stakeholder’ refers to the people or groups affected by a software development project. Stakeholders exist both within the organization and outside of it.

They may be end users, or they might simply be affected by the process. Either way they have a vested interest in the final product.

Input from stakeholders tells the company what kind of software is needed, suggesting ideas for features or problems it needs to solve.

They construct use-case diagrams and map workflows which guide the new software’s UI design. As a group they evaluate the merits of each others’ ideas, assigning an initial priority to the prospective feature list.

Stakeholders are in the best position to offer specific input on needs at their level. They know what will or won’t work within their workflows.

Plus, as representatives of their category’s interests they have a handle on any unique needs that may conflict with other stakeholders. Having that knowledge early helps developers find a compromise before serious problems arise.

Collaboration doesn’t stop after discovery, either. A more limited group of stakeholders is active during development to review prototypes and provide recurring feedback throughout the development process.

Why Are They Important?

Neglecting stakeholders is a risky proposition. First and foremost, without their input developers are working from an incomplete list of requirements. Surprise needs are bound to pop up during development.

These sudden additions cause scope creep, where the project grows past its original boundaries.

The initial time and budget requirements are forced to stretch to cover the new requirements. That isn’t always possible. It’s much more likely that some features have to be cut to meet deadlines.

Even when deadlines and budgets are satisfied, missing contributions have consequences. Lack of adoption is a serious risk. Sometimes software turns out exactly as leadership wants but isn’t used by employees.

They might already have more effective tools or find the new software doesn’t have features they wanted, or they’re just not sold on the software’s value.

Whatever the reason, their lack of enthusiasm translates into a wasted investment. This is especially true for smaller and niche groups whose needs tend to be overlooked.

There is room within development to add new requirements. However, those should come in response to ongoing feedback instead of being a band-aid for a weak discovery process.

Who Is Considered a Stakeholder?

While every development project is unique, there are some universal categories that can be used to guide stakeholder identification.

End users and beneficiaries

These are the people who will be most directly affected by the software. Their buy-in is essential. No matter how flashy or efficient software is, if end users don’t like it they won’t use it.

End users fall into three main groups:

Direct users

Those who will use the software directly are usually most concerned with how it will fit into their current workflows. They want to know that it solves a significant problem or otherwise makes their job easier.

Secondary users

Direct users interact with the software itself. Secondary users rely on the products of the software. New software needs to produce results in a format that fits into secondary users’ workflows.

Forgetting about this group can cause one problem while solving another, like suddenly generating reports in a format secondary users can’t integrate into their analytics.

Beneficiaries

These are all the people affected by the software’s products. The term encompasses a huge base of customers and vendors who focus more on results than process.

Their input should revolve around the services or information the software will provide.

Project build team 

Good software development is a balancing act between dreams and reality. End users sometimes create an unrealistic list of features and requirements.

The build team serves as the voice of reason that keeps the project within a manageable scope.

Their job is to find a way to fulfill as much of the “wish-list” as possible while meeting business goals and hitting time and budget targets.

Each member of the build team has a different focus:

  • Managers and company liaisons make final decisions about timeline, budget, and scope. They’re the ones authorized to add time or cut features.
  • Project managers shape the development process. They keep track of all the moving parts to maximize efficiency and serve as the point of contact for other stakeholders. Their primary interest is creating a solid product and leaving clients happy.
  • Developers build the software based on feedback from other stakeholders, but they’re also stakeholders in their own right. They have the technological expertise necessary to advise executives on which features are feasible and how long each would take to build.
  • Partners refers here to outside groups involved in the actual development process. They may be owners of third-party tools or a client’s business partners who need to ensure compatibility with their systems.

Authorities

Some people aren’t directly involved in the project but do have authority over it in some way. This includes legal and regulatory bodies, shareholders, and company owners.

Although they don’t have daily interaction with the software, they govern its usage. Be sure to get their input during discovery to avoid being shut down later.

Each of these categories can be further divided into internal versus external stakeholders.

Internal stakeholders are part of the client company: executives, employees, board members, and shareholders.

Their goal is to solve pressing business problems through optimized processes, increased sales, better insights, or some other measurable benefit.

External stakeholders lie outside the client company, such as customers, regulatory bodies, legal officials, and surrounding communities. They want to gain the most benefit from the project with the least risk to their own interests.

Both groups have what seem like conflicting motives, but in practice there’s a middle ground where everyone can find value. Collaboration by a diverse group of stakeholders is key to finding this middle ground.

Stakeholders-Software-Development
Source: Concepta, Inc.

Defining Stakeholders

Including every individual stakeholder in discovery would be insanely costly, both in time and resources. Fortunately, that’s not necessary.

Choosing representatives from every relevant group provides a good working picture of a project’s needs.

Look at all stages of the project from conception to actual usage to identify stakeholders.

Consider these questions when building the stakeholder list:

  • Who will use or be affected by the final product?
  • Who uses the current tool or software that the new software will replace?
  • Which departments use the products of both the current and proposed software?
  • How will workflows change? Will positions be modified or created?
  • What legal restrictions and regulations apply? Who knows enough about them to advise the development team?
  • Who has authority to make changes to the development plan once it’s finalized?
  • Are there any people whose support is absolutely vital to the project’s success? Whose buy-in is needed?

Stand-ins are often used for external stakeholders. Legal counsel can cover regulatory bodies and local government, for example, and focus groups serve as barometers of public opinion.

It’s also useful to consider who wants the project to succeed and who isn’t on board yet.

Bringing someone who’s reluctant to adopt new technology onto the stakeholder team can be a way to give them a sense of ownership that might change their mind.

Similarly, enthusiastic supporters can lend energy to a project others aren’t sure about.

Key Players for Ongoing Support

Interim progress meetings don’t need to include every stakeholder whose input is used during discovery.

Developers can gather requirements and suggestions from a larger group in the beginning, then identify key players to provide running feedback during development.

What sets key stakeholders apart? Look for those with two or more of these characteristics:

  • Will have direct contact with the final product (project managers and end users)
  • Are the senior representative of a group of important stakeholders (department heads)
  • Have unique knowledge or insight to offer which can shape development process (Subject matter experts)
  • Are so vital to success that the project can’t easily succeed without their support (executives, business partners, end users)

Think about whose input or approval is needed on an ongoing basis as opposed to those who simply want to approve the concept.

Also, keep in mind that stakeholders don’t have to show up in person to be included. For instance, agile development practices like continuous delivery open the door for gathering regular feedback from end users in the form of feature requests and reviews.

Sample Stakeholder Selection

What does stakeholder selection look like in practice?

Imagine a mid-level retailer – call them ExampleCorp – who’s working through digital transformation. ECorp wants to make their sales, marketing, and inventory data accessible by leaders throughout the company.

They decide to build a unified reporting dashboard that collects incoming analytics streams and displays them in an intuitive, easily understood format. Who are their stakeholders in this project?

ECorps starts by compiling a list of everyone whose input should be considered during discovery.

For this analytics project, they should consult:

  • Executives
  • Company liaison
  • Marketing team
  • Social media manager
  • Sales staff
  • Customer service department
  • Legal department (for advice about data protection regulations)
  • Administrative staff who currently pull reports
  • IT department who will maintain and train on the dashboard (including the database manager)
  • Company shareholders
  • Project managers
  • Development Team

Their key stakeholders, who come to progress meetings during development, are a smaller group.

The project manager, IT team, and company liaison still attend themselves. The sales, marketing, and customer service departments simply send representatives to report on how the most recent updates are being received by end users.

If a particular feature leans heavily towards a certain department more employees might want to come, but otherwise the representatives can carry concerns to the meetings instead of the entire team missing work to attend.

Final Thoughts

Effort spent during discovery translates into money saved during development. Take the time to gather input from all stakeholders and reap the benefits of a smoother, more focused development process.

Struggling with putting together your key stakeholder list? Take advantage of Concepta’s decade of experience to highlight the essential players for your next software development project. Your free consultation is waiting!

Request a Consultation