How Custom Software Gets Built (for Non-Technical CEO’s, COO’s, and HR Directors)

If you work at a large company with an enterprise IT team, there are many services and amenities you have. At a small- or medium-sized business, these are luxuries that you wouldn’t have available.

For example, when you and your team need a new software application to help you do your job better, you likely have an internal consultant, business unit technologist, or other IT professional at your disposal. This person can help you to weigh the pros and cons of building custom software vs. buying or subscribing to a commercially-available software application.

However, if you are in a leadership role at a much smaller company, that doesn’t have a large, internal IT department, this kind of business analysis and research will likely fall on your shoulders.

So what should a non-technical CEO, COO, or HR director do when considering whether to invest in custom software or settle for the inherent limitations of existing software as a service (SaaS) platforms?

Note: Mindset of your executive team is often the make-or-break for this kind of project. If your organization is open to new ideas about digitizing the business, investment in a custom software platform makes much more sense than hiring more employees to run highly-inefficient, outdated, dysfunctional systems. If your company’s executives are living in the past and don’t realize how much the marketplace is changing, no magic software platform can solve for your leadership’s critical misjudgment of competitive realities.

In this article, you’ll learn how to start a successful software development project that addresses your teams goals, plans, and challenges.

Draw on the Whiteboard

There’s no need to pull out the cliches. Everyone knows that a picture is worth 1,000 words.

If you’re like most business executives, you’re likely a very visual learner. There’s also an excellent chance that several people are your team are as well.

By drawing out your goals, plans, or challenges on the whiteboard, you make it easier to grasp and understand.

It’s very common to summarize and sketch out your overall approach on the whiteboard.

Whiteboards also provide a great way to recap a meeting. Then you can take a picture of it and save the contents along with the rest of your project planning files. You more easily document that snapshot in time and can communicate with other stakeholders that weren’t able to attend that particular meeting.

Map Out the General Workflow

Nearly all successful custom software projects start with a set of discovery meetings.

First, start general. Then go into details.

In a mid-sized company, for example, you almost always have different departments. Start a conversation about the general workflow — for example, from getting the client to getting paid for your product or service, as well as everything in between.

The goal is to identify

• Which parts of the system custom software can potentially help with
• Which parts of the system are not optimized
• Which areas have the most manual work and most errors

The key thing: Understanding process isn’t just about one person. It’s always about people that are responsible for their thoughts.

You start with the owner, then operations, then the CFO, and the CTO. Then you move onto different departments.

For example, a general manager may know how the overall system works, but he has no idea how to generate an invoice.

When mapping out the general workflow to plan a successful custom software project, start at the top executive levels of your company and work your way down to the lower levels of your organizational chart.

Focus on Pain, Requirements, and Prototypes

Now that you have a pretty well-documented understanding of how your company’s processes fit together, work with your software developer to define your project’s requirement and create one or more prototypes.

Before you move ahead, it’s critical that the business justification be crystal-clear. The overall idea of even exploring a custom software project has to make sense for your company.

In practicality, justifying these kinds of investments usually comes down to one especially relevant pain point. And by the time a company is looking for someone to help, there’s often more than one problem that they’re trying to solve. But there is usually a “final straw that breaks the camel’s back.” The pain has progressed to the point where a company is investing some time and budget exploring what a custom software solution would look like.

Call it opening a can of worms — or realizing that (at least) one link in the chain is broken. It’s not just one problem; it’s a systematic problem.

Operations managers are often trying to solve a problem in the easiest possible way — by creating a patch. Perhaps they hire a person to plug a hole and do this one particular job. Or maybe the company moves something around to temporarily fix a problem with the real solution to be addressed later.

As these problems pile up and accumulate, company leadership then starts looking for a more long-term, systematic solution rather than applying a series of Band-Aid fixes.

In mid-market companies, executives are usually laser-focused on what matters most: generating revenue and service. And these same executives are usually less-focused on less-glamorous areas like human resources, accounting, legal compliance, and document management.

Navigate Disagreements

If this is your first time navigating a project like this, don’t be surprised at the number of disagreements that come up. A big part of success — both for an executive sponsor like yourself and your counterpart from the software developer — involves acting as part referee, part judge, and part consensus-builder.

When you find that a discovery meeting devolves into five people arguing with each other, it becomes difficult to focus on building consensus on the direction for the prototype.

As a best practice, consider insisting on one stakeholder (one decision maker) early on. Yes, you’ll need discovery meetings with people from different teams to help you gather information. But when it comes to solutions, focus on just one person. If you’re the one reading this article, there’s an excellent chance that you are that person.

With bigger companies, there’s never just one decision. Everyone wants to get involved. And that’s where prototyping becomes incredibly valuable.

Instead of sitting and talking about how the software will work, the prototype shows how the software will work.

Key tips:

• Gather information from lots of stakeholders
• Get decision-making authority concentrated into one person (the solution must come from one person)
• Build a prototype to show how the software will work

The Bottom Line on How Custom Software Gets Created

In this article, you’ve learned how to lead a successful software development project that addresses your team’s goals, plans, and challenges.

You learned about the importance of being visual and drawing on a whiteboard. You got tips about mapping our your general workflow — starting at the top with more general probing, before going into more detail with other key stakeholders in your company.

And finally, you got insight into how to approach the inevitable discovery of pain, requirements, prototypes, and disagreements that come along with more custom software projects.

What type of software development project does your company need to address your team’s goals, plans, and challenges? Share your thoughts in the section for comments below.

To get more details on how custom software gets built, be sure to download our free eBook on “How to Plan a Successful Custom Software Project.”