The CTO’s Guide to a Killer Discovery Process: Part 2

This is Part 2 of a two-part series on the discovery process. To explore the earlier stages of discovery, read The CTO’s Guide to a Killer Discovery Process: Part 1.

Requirements gathering lays a solid framework for a project. Once the initial set is gathered, the developer has a general feel for what their client needs.

The next step is to visualize the solution in a way that allows all stakeholders to understand what it could look like at release.

In other words, it’s time to build a prototype.

Visualizing A Solution

A prototype is an interactive example of the proposed solution. It serves to validate the assumptions gathered from the client and allows for quick feedback.

Reviewing the prototype also gives the developer a better idea of the project’s intended scope.

This phase is just as important as gathering requirements. A well-constructed prototype helps clients fine-tune their requirements earlier, which makes estimates much more accurate.

In fact, solid prototypes are the key to a more profitable development process in general.

Wireframes are useful intermediary steps, but they don’t make very exciting presentations when trying to win over clients.

Software like Invision & Indigo Studio are excellent tools for creating interactive, highly visual prototypes.

Highlight a specific user flow to model the product’s main functionality.

Clients should be able to approximate usage closely enough to determine if there are missing steps or features that need to be added.

Resist the urge to get too caught up in design before the client sees the prototype.

Focus on bare functions at first. Have strong visuals, but don’t spend days on custom art assets that may get cut out as requirements are refined.

Only bring the design team in to polish the graphics after the basic functionality is approved.

Allow time for back-and-forth discussion on the prototype. This is the least expensive time to make edits or alterations, so encourage the client to share any concerns.

It’s also a good point to demonstrate additional features or expansions that could improve the final product.

“Finalizing” Requirements

Once the prototype is approved, create a detailed requirements document. List and detail every feature according to the user story.

Don’t just create a sparse feature grid; using visuals to communicate will prevent misunderstandings later on.

After the details are documented, work with the development team to get time and cost estimates for each part of the solution.

Start with broad estimates and work inward. Leave room for flexibility and changing requirements, but don’t pad the estimate unfairly.

Come up with a range where the developer can confidently commit to delivering the project.

Be clear about what the initial estimate covers and how changes would affect the price. Consider including varied tiers to illustrate what can be added later.

Final Touches

All of this leads to the final presentation. This is where the client is given a document which allows them to fully understand what will be built.

Clarity is essential in the decision-making process to approve the project.

Provide full transparency on what it will take to deliver each feature of the final product, and outline details like cost, processes, and schedule.

Good communication gets the project started with a clear vision for what the end deliverable should be.

Earlier phases should have ironed out the majority of issues, so this is essentially a review of everything that came out of the requirements gathering and prototyping phases.

In other words, it’s “reading back the order”.

A final word of warning: don’t rush through the final presentation assuming everyone is on the same page.

This is a developer’s last chance to wow the client and build confidence in their ability to deliver a killer end product. It will either win the client over- or send them looking for another developer.

Concepta takes a detailed, collaborative approach to discovery that’s proven to deliver products that meet our clients’ most pressing business goals. To find out what we can do for you, schedule your free consultation today!

Request a Consultation

The CTO’s Guide to a Killer Discovery Process: Part 1

discovery-process

A productive discovery process starts with thorough, collaborative requirements gathering.

Discovery lays the foundation for everything that happens during development.

Time spent productively in this phase has an exponential impact on a project’s chances of success – but it’s an unfortunate truth that discovery is often rushed.

Developers want to dig into an exciting project, or product owners are excited to start using a new tool.

Whatever the reason, a short discovery leads to a long road of misunderstandings and readjustments.

Running a killer discovery requires active listening and open communication.

The payoff is twofold: a smoother, more profitable development process and a better client-developer relationship that can lead to return business.

In this article, the first in a two-part series, explore the discovery process from initial interviews to preparing to create a prototype.

Why Discovery Matters

Discovery is a collaborative process that establishes the requirements necessary to build a specific piece of software.

By necessity it’s all about the client. Developers use interviews and probing questions to uncover the fundamental business problems or issues the client needs to solve.

When done correctly discovery:

  • Results in the highest quality final product
  • Prevents client-developer-stakeholder misalignment
  • Keeps the project on budget
  • Defines the product client needs and the way they need it done

This last point is a big one, and it’s the reason good discovery requires tact and insight.

Clients may not be clear on what they want. Sometimes they need help to frame their needs.

Discovery helps nail down the specifics to lay the groundwork for a productive development.

Client Interviews

Requirements gathering starts with interviews between the developer, the client, and relevant stakeholders.

This shouldn’t be a single meeting. Set up a series of sessions with space between to research and discuss.

Dig deep to understand the client, their business, and their existing processes.

It may be necessary to help the client identify stakeholders who should be at the meetings.

Listen to the client’s initial request, then question further to identify the true source of their pain.

They may think their problem is “our website is outdated and not driving conversions, so we need a new one” when the problem can be better stated as “customers are having trouble finding and using order functions on our old website”.

Be sure to touch on important issues like:

  • What is the business problem?
  • What does an ideal solution look like?
  • What special concerns are relevant to their domain?
  • Where can the developer add value?

Before moving forward, come up with user stories that help articulate the typical user.

What experience would the client like to create for their own customers? Outline each step in the process.

This will help with the prototype as well as testing later in the process.

Competitive Analysis

Once the first set of requirements are in, it’s time to brainstorm solutions.

Start with what’s already working by researching the “best in class” solutions currently used in the real world.

Note what others in the client’s domain are doing. Evaluate how well or poorly those solutions have worked out.

The goal is not to copy others, but to incorporate the best thinking available into a better solution.

It’s like writing code- good developers build on previous work to start from a place of success.

It’s also a great idea to find inspiration outside the client’s direct competitors.

Look at companies who have similar challenges, then bring together the most elegant solutions to assemble a dynamic, enterprise-focused brief.

What comes next?

The bulk of the requirements are collected during these two stages, though the team should be responsive to change within reason as development proceeds.

Now that there’s a good idea of what the client needs, it’s time to visualize a solution by building a prototype of the projected software.

Learn more about how to build the most effective prototype in Part 2 of the Keys to A Killer Discovery series, coming soon. If you want to know more about discovery and how our client-centric development process can help your business, set up a complimentary appointment today!

Request a Consultation

Which Business Analytics Trends Can Be Put To Use Today?

business analytics trends

Originally published April 6, 2017, updated Dec. 18, 2018.

The BI technologies which offer the best chance of success today are those that allow companies to take advantage of time-sensitive opportunities while providing more responsive customer service.  

One of the most important parts of developing a digital strategy is knowing when not to jump on a high-tech bandwagon.

Some technologies show potential in small-scale trials but haven’t had enough real-world usage to prove their worth to enterprise. Adopting too early puts companies at risk of losing their investment.

On the other hand, waiting too long leaves them in their competition’s shadow.

There’s a lot at stake in this balancing act. Digital transformation isn’t a luxury anymore. It’s critical for companies who want to stay competitive.

Even chains of three or four locations can fall behind their peers if they aren’t maximizing their data usage.

Of course, building up digital infrastructure costs money. Choosing the right technology is the best way to ensure a smooth return on that investment.

A number of business analytics trends are already picking up speed coming into 2019.

Some are years away from being able to deliver on their promises. Others have reached the stage where a company can reliably use them to gain a competitive edge while side-stepping the risks inherent to early adoption.

The best of this second group are outlined below. These are the trends to adopt for enterprises seeking to improve their data agility.

Predictive analytics

Predictive analytics as a field has existed since the late 1600s, when Lloyd’s of London used it to estimate insurance rates on seagoing vessels.

Until the rise of computers, though, it wasn’t a practical means of steering business.

There were too many variables for a human to consider in time to form more than broad predictions.

Widely available cloud storage and increased processing power changed that.

The field has seen a resurgence as the most efficient way to maximize data usage and feed a data-driven decision making process.

73% of companies consider themselves to be analytically driven, and predictive analytics are behind the most successful of these.

Predictive analytics detect deviations in patterns, generate insights based on evolving activity, and predict future outcomes from gathered data.

The benefits of predictive analytics are clearly demonstrated by the variety of practical applications in use today. One unexpected example is human resources.

Retaining experienced workers is a constant challenge for employers who must cope with turnover rates of nearly 20% (averaged across US industries).

The tech sector suffers from even higher turnover. Replacing lost workers can cost up as much as half their annual salary, not counting lost productivity during the training process.

Using predictive analytics, HR managers can find patterns in their employment data that highlight the reasons good employees leave and suggest the incentives most likely to make them stay: higher salaries, additional training, more appealing benefits packages, or in some cases transfers to more engaging positions.

The data also predicts which employees are most desirable to hire and retain.

There’s still a long way to go before the full potential of predictive analytics is realized. That said, the technology is maturing much faster than experts predicted.

Its current capabilities are more than reliable enough to justify making an investment.

Real time analytics

Real time analytics (also known as streaming analytics) give enterprises an up-to-date visualization of their operations.

It was a growing trend back in 2017, and today it’s living up to that promise.

In the traditional analytics model, information is stored in a data warehouse before analysis is applied.

This causes a gap between collection and results where perishable opportunities are lost.

There’s no rule that says data has to be stored first. It can be analyzed mid-stream to sift out data that will only stay relevant for a short time.

Companies then have the chance to make the most of the opportunity through swift action.

Information gathered by real-time analytics is usually displayed in a dynamic graphic format that doesn’t require a data science degree to understand, too. That makes it easy to act on quickly.

A business that can spot opportunities in time to take action makes much greater use than those left playing catch-up on trends.

The one caveat about streaming analytics is that they work best in data-driven cultures. Be sure to provide both technical training and executive support when launching a real-time analytics tool.

Chatbots and Natural Language Processing

Natural Language Processing (NLP) has grown from an internet novelty to a reasonably robust tool.

While it hasn’t seen as much use in the corporate world as its cousin, Natural Language Generation (NLG), it has developed enough for enterprise use.

The most relevant NLP application right now is employing chatbots to provide 24/7 customer support availability. Customers can interact with a chatbot using normal, everyday language.

The sophistication of a bot varies widely. Some have very basic account support capabilities; others can guide a customer from selecting a product all the way through checkout.

At this stage of maturity users generally know they’re speaking to a chatbot, though NLP has evolved to the point where the bot doesn’t frustrate users by getting stuck or spitting out garbled answers.

Instead, bots provide a clear, straightforward path to resolving common customer issues. The convenience of having uninterrupted access to routine account services tends to negate any annoyance.

Virtual assistants also fall under the heading of NLP. These let users request analytics and services using natural language and receive replies either out loud or projected to a specific device.

There are virtual assistant integrations for a huge variety of popular enterprise programs. Some even provide a path for the assistants to complete purchases using pre-approved sites.

Looking forward

Some interesting trends are gaining traction right now. Connected “multi-cloud” strategies are maturing, and research firms like Gartner have been tracking the application of real-time analytics to automated insight generation.

For now, though, the analytics trends are the ones which have demonstrated their utility and staying power.

While nothing is guaranteed in the tech world, even tech-averse companies can expect at least a reasonable ROI from their adoption.

Are you interested in adding to your business analytics toolkit? Get a full assessment of your BI needs!

Request a Consultation

5 Ways to Build Internal Support for Your BI Initiative

business-intelligence

Business intelligence may have transformative potential, but it’s also a significant investment.

Too often, that investment goes unrewarded. Last year Gartner found that 70% of corporate business intelligence initiatives fail before reaching ROI.

Even when projects succeed, they are used by less than half of the team.

The lesson to be learned from this isn’t to avoid business intelligence, though. There’s too much to be gained from using data to build a dynamic, factual model of operations and customers.

Instead, executives should address one of the root causes of BI failure: internal resistance and a general lack of adoption.

Try these approaches to build team support for business intelligence.

Use Success Stories to Build Enthusiasm

Employees have a full set of regular duties to handle. Learning and using business intelligence adds more to their slate.

A well-designed system will save them time and effort once established, but they need to be motivated to put in the effort to learn new tools.

Business intelligence seems like an esoteric concept to some. It can be hard to see a direct connection between data and results.

Instead of throwing out dry statistics, frame business intelligence in terms of what it can do for the team using real examples.

Before early initiatives, find success stories from competitors or comparable organizations. Use those to build excitement for the upcoming project.

Once each phase of the business intelligence project is finished the results can be marketed to the internal team to keep that positive momentum going.

When pitching business intelligence to the team, keep reviews specific but short. Choose clear metrics that demonstrate the actual effects of the project without getting bogged down in details.

For example: “Sales teams closed 23% more contracts last quarter using the new lead management system.”

Integrate BI into Daily Workflows

There’s no incentive to change if staff can default to the old system. People get comfortable in a routine, even when it isn’t effective.

They prefer to stick to what they know rather than learn new procedures.

Nudge resistant team members out of their rut by removing the option to use old systems whenever possible.

Don’t disrupt everything at once, but do have a schedule for phasing out old tools and switching to new ones. Publicize the schedule so it isn’t a surprise when old programs won’t open.

At the same time, make it easy to adopt business intelligence.

Be sure users are properly trained on the new tools, to include putting reference materials where they can be easily accessed by everyone.

Sometimes resistance stems from embarrassment or unfamiliarity, so also refrain from criticizing team members who need extra training or refer to training material frequently.

Create Business Solutions, not just High-Tech Tools

Misalignment between business needs and tool function is a leading reason for lack of adoption.

IT gets an idea for something they can build to collect new data, but it isn’t geared towards an actual business goal.

The product becomes busy work that distracts staff from core functions.

Business intelligence tools need to address specific pain points order for the team to use them.

They should have a clear purpose with an established connection to existing business goals. It’s also important that the new tool is demonstrably better than the current system.

If the tool takes ten minutes to update every day and the old system took five minutes twice a week, it won’t be adopted.

Along the same lines, favor simplicity in function and design. Don’t build an overly complicated multi-tier system only engineers can understand.

Aim for a unified dashboard with intuitive controls and a straightforward troubleshooting process.

Remember that the Team are Vital Stakeholders

Finally, don’t overlook the value of employees as stakeholders in any business intelligence initiative.

They have “on the ground” knowledge of internal operations that can guide the creation of a more targeted system. Take advantage of their expertise early in the development process.

Include key internal team members when gathering stakeholder input during discovery.

Go beyond management and choose representatives from the groups who will use the tools after release. Solicit and give serious attention to team feedback, both during and after release.

Bringing the team in from the beginning does more than build better software. It creates a company-wide sense of ownership.

When team members feel they had a hand in creating business intelligence tools, they become enthusiastic adopters.

Build Support, Not Resentment

Above all, keep the process positive. Encouraging adoption of business intelligence doesn’t have to be a battle of wills.

Focus on potential gains, not punishment for failing to fall in line. Bring the end users in early, listen to their feedback, and build a system that helps them as much as it helps the company.

When the team is excited – or at least convinced of the product’s value – they’re much more likely to adopt business intelligence in the long run.

Every level of operations can benefit from business intelligence. If you have a project in mind, we can help make a compelling case for BI that encourages everyone to get on board. Sit down with one of our experienced developers to find out more!

Request a Consultation

Keeping Decentralized Teams on Track

Decentralized-Teams

Outsourcing helps developers keep costs down, but working with decentralized teams can be difficult.

Get around these challenges with a combination of technology, targeted communication, and distance-optimized leadership strategies.

Decentralized teams – sometimes called distributed teams – are becoming a mainstay of software development.

They hit the sweet spot between value and quality, allowing companies to combine skilled offshore tech talent with dependable domestic development companies.

Working with decentralized teams comes with some unique challenges, though.

Here’s how to keep developers productive and motivated, no matter how far apart they are.

Choose the right project management and coordination software

Technology can bridge the physical gap between widespread team members. Productivity tools, task trackers, and communication programs create a shared virtual space where everyone has access to information on project status, upcoming milestones, and what is expected of them personally.

Tools only work when they’re used, though. Make software familiarization part of onboarding. Hold periodic refreshers, and have training resources available for employees to reference as needed.

Also, be sure there is a clear help and tech support process in place when the resources aren’t quite enough.

Clearly define goals and stick to them

Lay out the project overview and set specific objectives for each sprint. This should include daily, weekly, and full sprint targets.

Have a solid quality control process in place to make sure quality stays as high as productivity.

With distributed teams, sometimes the “chain of command” gets a little murky. During the earliest stages of a project, lay out the roles of the team as far as authority and regular duties.

Everyone should be able to answer questions like:

  • What are they responsible for?
  • Who do they turn to help if they finish early?
  • Who has authority to make changes and decisions?

Workers becoming overwhelmed or falling behind is another risk. Monitor progress checkpoints and keep an eye on team members who are at risk of missing targets. Offer extra resources when practical.

Remember to be realistic about workloads. Adjust future tasks if it’s necessary, but don’t keep moving the goalposts without a good reason.

Communication is key

When team members don’t see each other every day, things fall between the cracks. It’s easy for misunderstandings to arise.

Distance presents a barrier to asking for clarification. Workers have to wait on an email response or find a good time for a live chat or phone call.

If the team is in different time zones (which is common as budget pressures fuel the rise of international outsourcing) then trying to communicate in real time is especially frustrating.

This lag means that too often, problems get big before they are noticed. By that time, they’re more expensive and time-consuming to fix than if they were addressed right away.

Always err on the side of too much communication rather than too little. Have clear lines of communication set up between all team members.

Foster a culture of collaboration and free interaction; don’t criticize or penalize workers for reaching out for help from a team member when they can’t get a fast leadership response.

Don’t overlook the human element

Workers are more productive and motivated when they feel connected to the company, so keep the human element in mind.

Hold regular video chats and phone calls instead of relying entirely on text-based communication. Don’t discourage inter-company friendships or social side-chat as long as work is still getting done

It’s also important to relay praise as well as constructive criticism.

Workers need to hear when they’re doing a good job instead of only getting feedback on mistakes.

Stay in touch – but don’t micromanage

Last – but not least – keep in mind that communication doesn’t mean micromanagement. Stay on top of the team, but don’t get in the way of their productivity.

That is less of a contradiction than it seems when technology is considered. If communication is emphasized and team members are reliably using the task tracker, it’s easy to see where they are at any given moment.

Avoid interrupting a productive day with questions that can be answered by the task tracker or another collaboration tool.

Assign tasks and priorities, but whenever possible let team members decide how to do things. They were hired for a reason; trust their expertise until given a reason not to.

Concepta has over a decade of experience working with decentralized team around the world. Our combination of local and distributed teams lets us offer competitive prices without sacrificing quality. Find out how your company can benefit from our system today!

Request a Consultation

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