Keeping Decentralized Teams on Track


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


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

The Best Project Management Methodology for Business Intelligence


According to the Project Management Institute, Agile methodologies have become the gold standard for IT projects. 40% of organizations report using it most of the time. When companies just beginning to incorporate Agile are included that number jumps to 71%. These companies are responding to the sizeable increase in performance realized from Agile-guided projects, which are 28% more successful than those developed with more traditional methodologies.

The benefits of Agile aren’t limited to IT. Experts are starting to incorporate Agile ideology into other highly technical domains, most prominently business intelligence.

Agile methodologies have the potential to drive dynamic, responsive business intelligence processes.

What are the Core Values of Agile?

Agile sees a lot of use in software development, but its core principles have wide-ranging applicability. Consider the primary Agile characteristics:

  • Early, frequent delivery of usable products
  • Openness to change when doing so provides competitive advantage
  • Working solutions as a measure of progress
  • Sustainable development
  • Quality over quantity
  • Efficiency in planning and execution
  • Communication at all levels

At heart, Agile is about providing outstanding customer service and quality in as efficient and sustainable a manner as possible.

That has a lot of appeal for domains which can otherwise get bogged down in obscure details.

Business intelligence is one such field. It requires both technical skill and business savvy, and sometimes striking a balance between the two threatens to derail a promising project.

Challenges to Business Intelligence Projects

The term “business intelligence” covers a lot of ground.

It’s applied to a wide spectrum of techniques aimed at giving leaders the information they need to make logically sound, data-driven business decisions.

This includes finding inefficiencies and workarounds for them, cutting costs, increasing profit margins, and highlighting opportunities in time to act on them.

As might be expected from such an ambitious goal, business intelligence projects can have erratic success rates.

There are so many moving parts that one misstep potentially jeopardizes the entire project. Some of the most common reasons BI initiatives fail:

  • Data sources are insufficient or inaccurate
  • The final tool doesn’t meet the needs of users
  • Products take so long to create that they’re already outdated on release
  • Poor user experience ratings
  • Mismatched team schedules and technical philosophies

What’s the Best Methodology for Business Intelligence?

Taking Agile methodologies and incorporating them into BI projects makes it possible to mitigate or even avoid these problems altogether.

For instance, following the discovery process is a good way to create a comprehensive requirements list.

Gather all stakeholders together and find out what data they want or need on an ongoing basis. Look for overlapping needs as well as outliers.

Prioritize requirements as a group. Doing so makes the process transparent and reduces the risk of one category of stakeholders feeling minimized (which affects adoption rates).

Short, iterative sprints are excellent for breaking up obscure technical problems.  Emphasize creating something that can be used now and build on that.

Provide additional workable tools, processes, or data source at the end of each sprint. Think smaller in size but higher in quality for sprint scope.

Something that may work when stakeholders are skeptical: organize and prioritize projects by place in the business process to allow progress to build momentum.

As people see the value of Agile, they can more confidently embrace its methodologies.

One of Agile’s greatest strengths is regular feedback. Maintain an open channel of communication with those who will be using the project.

Welcome feedback and questions as a way to provide better data, and incorporate changes as they’re needed. Focus on user satisfaction as a measure of success.

Speaking of measuring success, the continual quality assurance process Agile recommends will keep business intelligence resources in top conditions.

Test systems throughout the development cycle to spot problems early, when they’re easiest to fix.

Schedule specific “source updating and validating” sprints at regular periods to eliminate the threat of using outdated data.

Aggressively seek out weaknesses to fix them as soon as possible. Tools that don’t work don’t get used, so proactive testing and repair protects the original investment.

Bending the Rules

A final word of caution: don’t get so dedicated to Agile that the business intelligence project suffers.

For example, many companies spend longer in the “discovery phase” than software developers might because business intelligence requirements tend to be highly complex.

Others have to go back over a testing phase to iron out a tricky component. That’s okay- if a certain part of the project needs more time, give it more time.

At the end of the day Agile is about results, not rules. Adopt the Agile concepts that offer an advantage and don’t stress over those that don’t apply.

There is more powerful business intelligence software on the market than ever, but all those incoming data streams can be overwhelming. Request a free consultation to find out how Concepta can organize all your business intelligence into an intuitive, customizable dashboard.


Request a Consultation

10 Ways to Avoid Budget Overruns In Software Development

Budget Overruns-In-Software-Development

Fierce competition for clients has led to a change in the way software developers work. Rather than sending an estimate up front and billing the total cost at project’s end, they’re bidding the full amount they will charge for a project. Additional investments have to be agreed on in written change agreements.

As a result, every budget overrun cuts directly into the developer’s profits. It’s critical that executives work with their project managers to ensure things go as smoothly as possible.

Towards that end, here are ten quick tips for keeping budget overruns under control.

Use Agile methodologies

Agile project management is a big reason software failure rates have begun falling for the first time in over a decade. The iterative development process allows for continual feedback and adjustment; small corrections early on have more impact than large changes later on.

Don’t skimp on the Discovery process

Extra time in discovery is the single most influential factor on a project’s success. Taking shortcuts here gives developers a handicap they may never overcome. Without taking time to see the big picture of what clients need, they can’t fully understand a project’s scope. The danger here is that developers could underbid and commit themselves to delivering more than they expected.

Be realistic about how much teams can get done in a sprint

Use historical performance information from similar projects rather than hopeful estimates. When possible use data from the actual team that would be doing the project.

Leave room for error

The most urgent goal may seem to be outbidding the direct competition, but never bid so low that it becomes impossible to deliver profitably. There are always surprises, so plan for them. Include dummy sprints in the budget and timeline to allow for unplanned changes. If they’re not needed, the client gets a pleasant surprise when their software is done early.

Use (and listen to) experienced project managers

80% of high-performing projects are led by a skilled project manager, so resist efforts by the client to trim costs by cutting the position from the budget. Listen to the project manager’s advice and experience during the budgeting phase. Empower them to keep up efficiency and morale within their team with as little micromanaging from above as possible.

Use project management software (and make sure it’s adopted throughout the team)

40% of companies don’t use project management-specific software to manage their projects. There is no reason to juggle spreadsheets and calendar apps when there are powerful, easy-to-use programs (like Basecamp) designed to keep projects orderly and on schedule.

Stay vigilant against scope creep

Don’t view scope creep as inevitable. After all, a thorough discovery process should minimize its effect. This doesn’t mean developers should refuse to make any changes at all; it’s more a reminder that the bid was calculated based on specific requirements. Agreeing to additions and changes outside the scope threatens the budget and the timeline. If a change will affect the project in a large way, go back to the customer and negotiate a change agreement to protect everyone’s interests.

Prioritize automated testing when appropriate 

Automated testing provides wider and more consistent coverage than manual testing. It allows developers to catch problems earlier, when they’re easier to fix. It isn’t applicable to every project, but it saves time and money when it is.

Utilize risk management techniques to mitigate problems as they arise 

Project managers should have both contingency and mitigation plans in place before a project starts. Contingency plans are meant to handle situations which are highly unlikely but could kill a project if they occur. Mitigation plans should minimize the effects of lesser situations which are more likely to appear.

Emphasize communications at all levels 

Communication is the key to staying on budget. There should be a continuous flow of information and feedback between clients and project managers, project managers and their teams, and project managers and senior leadership. Check in after each sprint at the very least. Having knowledge as early as it’s available puts developers in the best possible position to plan, adjust, and act.

It’s impossible to see the future, but following these guidelines lays the groundwork for being prepared to meet unexpected challenges as they arise.

At Concepta, we believe that what’s good for clients is good for developers. Projects that stay on budget can be delivered on time and at a higher quality than those that run over. To explore how much we can achieve within your company’s budget, set up a free consultation with one of our experienced representatives today!

Request a Consultation

What To Look For In An IT Project Manager


IT projects are finally seeing an improvement in success rates after years of struggle. According to 2017’s Pulse of the Profession report, companies are wasting 21% less money on failed IT projects than the year before.

Agile development methods are one contributing factor, but what really drives success is the leadership and organizational skills of experienced IT project managers.

A quality IT project manager sets the tone for how an entire project will proceed.

They mean the difference between a project that barely meets standards (or fails entirely) and a project that succeeds well past expectations.

In fact, 80% of high performing IT initiatives are led by trained project managers.

With results like that, it’s worth taking some time to explore how to spot a good project manager.

Why IT-Specific Project Managers Matter

Agile software development has shown its worth, but it does has a lot of moving parts. Project managers make sure all those diverse components come together to create a high quality end final product.

They handle regular management duties like coordinating with their team members, overseeing operational requirements, controlling costs, and ensuring quality.

On top of those, the Agile process involves frequent and detailed communication with clients.

IT projects in particular can be challenging to manage without specific technical management experience.

Those unused to managing software projects often don’t have the knowledge base to understand challenges presented by technology.

They can’t understand technical jargon, which makes it hard for them to serve as an intermediary between clients and engineers.

Non-technical PMs also have trouble managing sprints and adjusting a project’s overall scope in reaction to change.

Qualities of Good IT Project Managers

Hollywood is full of unconventional leaders and quirky team dynamics, but in the real world there are some traits found in every project manager.

  • Organized enough for the whole team: The best PMs are more than just tidy. They’re organized enough that everyone under and above them can easily understand the state of the project at any given time. While they can’t do every bookkeeping task for their team, they can reduce the complexity of tracking efforts so technical team members waste as little time as possible.
  • Facilitates good communication: Communication is key to successful software development, and project managers serves as the communication hub. PMs need the written and verbal skills to clarify client requirements, convey those to the developers, and translate technical concerns back to the client as needed. This requires at least a user-level understanding of technical jargon. Empathy is also critical. Project managers must foster relationships where clients and developers both feel comfortable sharing ideas and concerns.
  • Strong business sense: Project managers go beyond just getting the project done. They make sure it gets done profitably for all involved. Having a good idea of the business value desired by a client allows them to develop with an eye towards maximizing that value. Plus, many development firms offer bundles or set package rates to stay competitive. Ballooning costs can’t be passed on to clients, so project managers must be absolutely on top of budgets. The best guideline is to look for PMs who are aware of where a project fits within both their own company’s business goals and their client’s digital strategy.
  • Encourages teamwork: Teamwork isn’t just a buzzword. Good software is built by good teams. A smart project manager recognizes and values every team member’s contributions. Rather than waiting for conflicts to impact productivity, project managers actively work to keep the work environment conducive to good morale and motivation. They should develop a detailed understanding of each member’s capabilities to make budget estimation and spotting potential problems easier.
  • Cool under pressure: This quality is hard to spot in an interview but easy to see in action. Project managers have to be able to calmly assess a chaotic situation and find the most efficient path through. Many a project has been saved from failure by the timely intervention of a project manager, so quick decision-making skills are also a must.

A final caution

97% of Fortune 500 companies say good project management is critical to project success – yet somehow, projects are still begun without an experienced PM at the head.

Nine times out of ten the reason for skipping the project manager is financial.

In the absence of experienced leadership, though, IT projects risk becoming one of the 17% of project that fail so badly they threaten a company’s future. They’re nearly guaranteed to run over schedule and cost more than twice their initial estimates.

That makes cutting out project management counterproductive as a cost-saving tactic.

The bottom line is simple: there is always room in the budget for project management.

At Concepta, our IT- trained project managers stay with teams from project to project, giving them a deeper rapport and more understanding of what their team can do. Set up a complimentary meeting to find out how you can harness their skills to turbocharge your next development project!

Request a Consultation

Avoid Organizational Failure by Programming a Path Through Technological Complexity

custom software development

The parallel growth of cloud data storage and analytics tools has created an interesting operational environment for enterprise. Businesses can store more data than ever, and they have access to thousands of programs designed to wring significance from every last byte.

That data powers the new generation of enterprise apps offering quick analysis, sharing, tracking and even automation of repetitive tasks. 74% of executives found automation to be “very beneficial” or better to their bottom line.

More software tools for leaders should translate into better information and more time to focus on corporate strategy. They do deliver on information, but the promise of more time rarely seems to appear, at least not for senior management. If automation and analytics software is really increasing productivity, why does it seem like leaders are busier than ever?

The Impact of Technology at the Enterprise Level

The answer lies in the side effects of increasing technological complexity. While enterprise software offers expanded capabilities, it adds extra tasks to managerial workloads.

Nine out of ten managers in a UK corporate efficiency survey reported having to perform administrative tasks that fall outside their job descriptions in order to keep functional spreadsheets current or provide status updates.

The time spent on these additional tasks added up to around 15 hours a week for most, with 20% spending three days or more. As a result, up to half did not have enough time to focus on strategic initiatives.

Eliminating software isn’t a practical option for reducing complexity. Enterprise software adds too much value to businesses. Automation through marketing apps contribute to a surge in leads for 80% of marketers, with 77% adding that their conversions went up as well.

Sales are only one benefit of “appification”. . . Enterprise apps can increase productivity by an estimated 40%, according to the Harvard Business Review. A 40% increase in productivity across the board would be worth the hit to executive workflows even if there weren’t a ready solution for complexity.

Fortunately, there is. An integrated business management solution paired with business intelligence software can minimize the problems inherent to technological complexity. This combination adds an additional layer of analytical power and enables ready access to data throughout an organization.

There are some decent pre-made BMS programs, but mid-size to larger companies often find that their operations are too specialized for standard software. They run into problems where their own internal apps don’t communicate with the BI software.

The most effective path to resolving this issue is by building a custom software development solution.

Exploring technological complexity

Complexity refers to a company’s comprehensive technology structure. It includes every piece of software used to plan, conduct, track, adjust, and review business activities. (Legacy systems from the company’s early days are technically rolled into complexity, though most businesses phase those out as new technologies are adopted.)

Technological complexity is both a blessing and a curse for enterprise. Executives have access to an incredible amount of data on everything from market activity to customer behavior, and the rate of growth shows no sign of slowing down.

To put some perspective on that, there were five exabytes of data stored from the beginning of time through 2003. Now, that same amount is created and stored in 48 hours. Humans create 2.5 quintillion bytes of data every day.

As the amount of data available rises, so does the number of programs necessary to manage it. There are currently 4.6 million apps available between the Play store and the App store. While many of those are games, a fair percentage are enterprise focused.

A recent survey showed the four most common enterprise usages for apps were email and communication, sales and marketing, social media, and document storage. The applications are limited only by programming ingenuity and legal restrictions.

adoption rate for enterprise apps
Source: okta

Productivity and analytics tools are immensely attractive to executives because of the functionality they offer.

Project managers are able to communicate with their teams remotely using pictures and files, cutting down on meeting time.

Marketers can initiate and monitor email campaigns on a single app. Some social media analytics apps go so far as providing insights on how to improve the customer experience that are impossible to get anywhere else.

There are, as mentioned earlier, some unpleasant consequences of growing technological complexity. To remain useful, software needs regular management. Someone has to log in, update information, and download reports for each individual app or program.

Most of the time updates take less than five minutes, but that adds up when every program needs daily input.

Correlating results across platforms gets complicated, too. When a company has upwards of a dozen analytics tools, preparing for a weekly progress meeting could take an entire day.

The process involves going through the “Three As” for each program: data must to be accessed, analyzed, and associated with data from other sources in order to build a complete picture.

Complexity itself isn’t the problem. Complexity is more like a growing pain, a natural result of transitioning to a data-driven corporate culture.

Data driven decision making (often shortened to DDD) takes advantage of modern analytics technology to shape corporate strategy.

It’s at the heart of the current shift towards analytics software. Results are striking. In a sales environment, increasing data usability by 10% can increase sales per employee by 14%.  

In short, knowledge is power.

Enterprise software and apps are the tools that give executives the insight to make informed choices.

Moreover, once a company optimizes its mobile app strategy it can potentially gain 240 hours per employee annually in increased productivity. The advantages of enterprise software are clear; leaders just have to find a way to control complexity.

Measuring The Scope of the Problem

In 2016, enterprise app usage increased 20% over 2015 rates. The average company used 10-16 apps to manage their operations, with marketing heavy organizations nearing 65 distinct apps. That number only includes off the shelf cloud apps, not home-grown solutions.

usage of enterprise apps
Source: okta

There isn’t a significant correlation between company size and the amount of software they use: all but the smallest family-owned businesses suffer from technological complexity at near-equal rates.

Most analytics software is connected to the company’s central website, with 13 toolsets integrated into the average site.

56% of marketing executives reported using one to five separate tools for CRM. That’s likely a conservative estimate, since there were 450 marketing applications available as of January of this year.

In fact, most people tend to underestimate the amount of software they use on a daily basis.

In a Hubspot survey of salespeople and marketing, the majority of those surveyed claimed they regularly used less than five apps. Hubspot’s audit of those same companies found they still fell within the 10-16 app average.

The time spent maintaining these tools is surprising. 82% of salesmen spend an hour every day managing software tools. That’s an hour spent solely on management, not usage or drawing reports.

Pulling reports from different sources took another hour for 75%, relegating maintenance tasks to IT departments is a less efficient option given that their labor is typically more expensive.

Every hour spent on analytics maintenance is an hour away from an employee’s regular tasks.

Worse, some of those hours are wasted on redundant processes. 65% of survey respondents said up to five of their programs overlapped or were redundant.

Different departments might choose to license similar software, or two related programs might need the same information for distinctly different purposes.

Whatever the reason, the end result is higher labor costs and hampered productivity.

Frustration with cluttered and redundant programs can leave a company with disgruntled employees who refuse to use enterprise software at all, as a recent survey of 4000 office workers shows.

85% felt that enterprise software made them more productive, but only 12% of workers say they rely on apps to at work.

Another 88% cite poor user experiences as the reason for avoiding apps, including ones paid for or made by their employers.

Of the 12% who use enterprise apps, less than half feel it provides an elegant, intuitive user experience.

Executives aren’t blind to the effects of this process drain.

Dasher CEO Jesse Boyes explained his concerns: “Minimizing complexity is a big deal for us. Every day we just want to come in and focus on building product, so every point of friction along the way really hurts us. The efficiency of getting your tools and processes smoothly integrated really quickly is very important to us.”

Dasher isn’t alone. 74% of companies report that complexity issues are preventing them from reaching organizational goals, and 8% have had to deliberately slow their growth in order to fix problems caused by complexity.

business complexity
Source: SAP

Off-the-Shelf ERP Vs Custom-Built Integration

Used here, custom programming doesn’t refer to rebuilding a company’s software from the ground up. It’s a process of building a logical path between workflows, collecting data from enterprise apps and tool kits, and presenting that data in a way that gives executives a live view of operations.

There are several off-the-shelf programs that serve as an intermediary between enterprise apps.

Some can even perform BI analytics on a limited range of apps. Regardless, custom programming is still far and away the best solution for managing complexity.

This approach outperforms boxed programs in three main categories.


Off-the-shelf programs are generalists, not specialists. They have a set of features with broad appeal, tools designed to be functional to as many people as possible.

This means that while a company can find software that does some of what they need, there’s unlikely to be something pre-made that fits all of its processes.

Two things tend to happen next.

First, the company seeks out more software to cover the gap in their management routine. Adding these new programs creates asymmetrical complexity that can cause problems later in the company’s lifetime.

Second, employees begin to reshape their workflows to incorporate the unused portions of the software. This seems like a sensible use of resources- except those unused features were being ignored for a reason. They aren’t needed, and using them gives a false sense of innovation and productivity.

During custom software development, the developer creates a system that addresses the client’s specific requirements. The system isn’t limited by a set selection of features. It does what the customer needs and no more, bringing the number of moving parts down to an absolute minimum.

This tailored approach makes the software work the way the company works, not the other way around.


OTS software only functions well with other software when one or both programs are designed for interoperability.

Limited communication between software is a primary cause of redundant administrative tasks; since the individual programs doesn’t share with each other workers have to enter the same information over and over.

Integration isn’t a challenge for custom programming. Where programs don’t mesh well, developers can write code that connects them to each other, routes them to a central dashboard, uses their data to update a different app, or whatever is needed to facilitate an efficient workflow.


This is an area where custom programming wins by default because traditional ERP systems don’t have analytics capabilities.

An ERP simply gathers data and presents it in one location. Developers building a custom solution can choose to channel their client’s information into a program like Power BI, creating a constantly-updated dashboard that displays the output from all the feeder programs.

Even in-house apps which aren’t app-store friendly can be connected so their data flows through Power BI.

Looping in advanced analytics is one of the highlights of creating a custom BMS because of its ease of access.

Instead of opening each app and tool, extracting the data, and arranging it into a useable format, leaders merely open their central dashboard and tab over to a prearranged screen.

Those reports are already updated and displayed in relation to each other. The system generates graphs and charts to help visualize the requested data, editing them periodically so that the information shown is always the most current.

Once the custom BMS is in place and tools such as Power BI is enabled, executives can request more analysis of their data using a natural language query system. This goes beyond a simple file request.

Natural language programs have advanced to the point where executives can make complex demands such as, “What were the total sales of product X in the South Region last quarter?” and expect accurate output.

A Client’s View of The Custom Software Development Process

Off-the-shelf products can’t deliver the same level of performance without custom programming, so why do so many companies shy away from an individualized approach?

The most commonly cited concerns are unwillingness to disrupt current activity and a lack of understanding about the development process.

The custom software development process imposes a reasonably light burden on the client organization. As a demonstration, this section will describe the steps involved in creating an integrated BMS using custom programming.

custom software development process
Source: Concepta

The guide begins after the client company has engaged a web development firm to handle the process.

Most firms will require a deposit as well as a rough estimate of the overall budget for the project before moving into discovery.

The first and most important phase of custom programming is discovery. Everything that follows will stand on the foundation built during discovery, so communication is key.

Misunderstandings that make it out of this phase cause expensive delays down the road. That’s only one of the reasons why good enterprise-level IT projects fail.

To help prevent this, the developer’s consultant does research before the first planning meeting to get a general idea of the company’s scope and prepare an outline of industry-specific questions.

In the initial meeting, the client runs the consultant through their normal business operations. They then hash out the company’s requirements from a user-facing perspective. Instead of jumping straight to the process, the ends results are captured. These requirements are phrased as statements:

  • I want to be able to enter a customer’s data and have it populated across these platforms.
  • I want these two applications to generate a joint weekly report.
  • Our current estimate procedure requires three apps; we want to narrow that down to one field-friendly process.

Striving for end goals rather than listing every step of the process has two purposes.

First, it helps clarify what the programming needs to accomplish without getting bogged down in minutiae.

Second, it leaves room for programmers to suggest more efficient ways to handle a task that the client might not be aware of.

Once the requirements are finalized the consultant takes them back to the developers to produce a wireframe. This minimalist sketch serves as the blueprint of how the product will function.

In a sense, it’s the earliest prototype of the end product. It allows the customer to check the flow and make changes.

Wireframing goes back and forth several times as the developers respond to client feedback.

When the client approves the final set of wireframes, design work begins. The designers (who may also be the developers) work with the client to create a visual style for the interface.

In most cases the design features the company’s brand colors, but the focus more on creating an intuitive layout.

Remember the 88% of workers who won’t use an app if it’s too much of a hassle? This is the step where the company can draw those workers in. The more employees who buy into the technology, the more impact that technology can have on the bottom line.

With requirements, wireframes, and design sorted, there is enough information for the consultant to put together a realistic estimate. Up to this point the project has been put together to fall in line with the client’s initial estimate.

Now the consultant can add up the hours and resources necessary to turn the wireframe design into a functional system and provide a more accurate assessment of cost.

There is no standard price for custom programming solutions. Everything depends on scope.

For a BMS “dashboard” like this project, the biggest factor affecting price would likely be complexity. How many programs need to be integrated into the system? Are those off the shelf apps or in-house software with unfamiliar code?

The more intricate the coding, the longer it will take the developers to complete. Other considerations include size, creative design requirements, and fees associated with the Business Intelligence software.

It’s not unusual to go back to wireframing a few times from this point. The original estimate was a general ballpark figure meant to cover all possibilities.

When the total costs are calculated clients may decide they have room in their budget for more features. This means the cycle of wireframing, design, and estimates can repeat a few times until the client agrees to a plan.

The next section of the process takes place at the development firm.

Project Managers use Agile strategies to plan and oversee a series of programming sprints culminating in a finished product. At the end of each sprint is a deliverable, usually one that builds on the previous deliverable. These are brought to the client for feedback.

agile methodology
Source: screenmedia

Having each deliverable approved by the client reduces the risk of making an error on the second sprint that invalidates everything after it.

In addition, it increases the likelihood that change orders will come at a more efficient time in the process (ie, the sprint which is about to begin rather than several sprints prior).

Each deliverable has been checked by the end of the project, but that doesn’t eliminate the need for final QA and testing.

Both automated and manual testing methods are used.

Automated testing provides information on load testing and shakes out programming errors while manual testing make sure the interface is user-friendly.

When the interface clears QA it’s ready to be delivered to the client and phased into use.

Consultants help plan training sessions to guide employees through their expanded capabilities and the streamlines maintenance processes.

After this is completed, the development firm’s responsibilities shift towards software maintenance.


Complexity is here to stay, but it doesn’t have to impact the bottom line. Turn to custom software development solutions to personalize your BMS simplified technological integration and boost analytical power.

Are you interested in hearing how Concepta can help minimize your complexity issues? Schedule an exploratory call with one of our consultants!
Request a Consultation