THE OVERLOOKED REASONS WHY YOUR PROJECT IS FAILING: YOUR DEVELOPMENT TEAM NEEDS BUSINESS KNOWLEDGE

The Overlooked Reasons Why Your Project is Failing: Your Development Team Needs Business Knowledge

Let’s face it: not every software development project represents the height of technical challenges. A good software developer needs knowledge of the business at hand to be truly effective. A truly great technical resource, a Tech Titan, will have an innate ability to pick up business knowledge fast. For this post, we’re going to address the issue of business knowledge, what it means, and when you absolutely must hire someone who possesses it. Buckle up kiddos, let’s ride!

What Exactly Do you Mean, “Business Knowledge”?

As we mentioned in the article on Technical Prowess, it’s hardly ever about the code. And likewise, when it comes to building business software or really software in general, the battleground is communication. The key to communication when it comes to software is to understand the words and images that will be used to define that software, what we call the lexicon.

The Lexicon and Why You Must Have One

The lexicon is the set of terms used to describe a particular business, process, role, or component, especially as it relates to the development of software as part of that process. In general each large industry has defined their own lexicon for various things – which might make you think, “why are we worried about it at all?” You’re right. It’s the freakin’ 21st century and by now people in finance should know their lexicon and people in healthcare should know theirs. There are a couple of problems with this: 1) everyone seems to view the world a little bit differently, and 2) lexicons change over time as technology and business processes change. And a close third, new markets often need entirely new lexicons – and the good ones make up their own terms (Google something or Uber somewhere).

Death by a Thousand Tiny Menacing Cuts

Suffice it then to say that defining the lexicon and agreeing on it is one of the most challenging parts of a business software project. We’ve seen the dark side of this on many projects and it is often “death by a thousand cuts”. As it relates to the productivity of a software developer, confidence in their understanding of the business lexicon is paramount to their ability to make accurate decisions on the fly – which means avoiding dragging 6 people into yet another meeting about “status codes” and what they mean. And then because you forgot to invite Sue in accounting, you’ll have to meet <again> and change them again and now your Tech Titan software developer is completely BS with you because they’ve got to change the code <again>, re-run the unit tests, and on-and-on until finally someone “gets it”.

Why is it Important Again?

This is really understated, so we’ll say it again in bold letters in the middle of the page:

The confidence of a software developer to make accurate decisions on the fly is directly related to their confidence in their understanding of the lexicon.

The ability (or inability) of the leaders of a software development project to establish the lexicon and gain consensus for it across their constituency is paramount to being successful. We’ve seen this time and time again. And we’ll get into it in more detail in a later post, but many think that agile software development processes allow them the flexibility to change these kinds of things frequently – and that’s simply not true. The process allows for flexibility of the work being done, but the work still <must> be defined. More on that later – let’s get back to business knowledge.

The Business-Process-Technology Model

If the business process is poorly designed and ill-defined, software is not going to fix it. If no one can fully agree or understand the business process, building software will be a royal pain-in-the-a$$ and you’ll alienate any decent resource (or Tech Titan) that you might have on the project. Get your sh*t together first, define your processes, THEN build some software to support it.

This could very well be the giant sucking sound of the United States’ GDP over the last few years – people at giant companies taking on huge projects spending a bajillion dollars and not having a clue how to even agree on the lexicon and business process, much less to define what they are building. But we will save those detailed rants for another time – just remeber: if you don’t have the business process straight, no amount of software will fix it.

The Most Efficient Way to Develop Software Is…

These days many companies struggle with all of the roles and types of resources required for a software development project. Business analysts write and review requirements, Quality Assurance people write test cases and execute them, Project Managers manage the time and schedule, DevOps folks do their voo-doo, System Admins keep things running. But let’s take a step back and look at the reality of this.

The most efficient type of software development ever is done by one person who owns the lexicon; creates and establishes business processes; creates the requirements; and designs, implements, and tests the software.

That’s a big whopping pile of profound right there – but think about it: avoiding any disagreement on the lexicon, there are no meetings. Nailing down the process – no discussions and few changes. And when the person who builds is the one who knows the requirements, there is no room for question. This is one of the many areas where the construction metaphor for software development fails: this kind of thing rarely exists in construction environments. Building a house often takes a small army of specialists. Building software doesn’t require it.

Yes, the one person development team is the most efficient but is simply not practical for writing business software for an enterprise, at least projects that have large user bases, big ol’ lexicons, many many requirements, and maybe more than one server. You need a team of specialists, like building the house. But the big difference is this: everyone is at some level an analyst.

Sometimes We All Must Be Business Analysts

One big difference between a hammer-swinging code slinger and Tech Titan is that the Tech Titan is an analyst as well as a developer. They’ve developed an understanding of the lexicon, the industry, and the business process and they are able to apply that in the various situations that they encounter as a software developer. A Tech Titan also asks the right questions and finds out the details before running off wily-nily coding away at something that might not be correct.

Projects need the questions, they need the refinement of lexicon and requirements, they need the finality of consensus on those and movement of value from those things into code, and code into software, software into the business process. This is where the value is generated. Tech Titans jump gaps. Hammer swinging code slingers do not.

The 3 Scenarios When You MUST Have Someone With Business Knowledge

We’ll save the detailed team structure evaluations for a later time, but there are 3 key scenarios where you absolutely <must> have someone with business knowledge of the domain of your software development project.

  1. Everyone else doesn’t.
  2. Your domain is complex.
  3. We’re out of time Captain!

Herding Cats and Other Means of Wrangling Effective Software Out of Noobs

Let’s face it – the industry today is riddled with “experts” who can’t deliver software to save their lives. But they coded their Grandmother’s knitting website in Wix and here they are, applying for your gig. Today everyone is a developer and really no one is. And unless you’re living in the rarefied air of Silicon Valley or some other think tank, the real good people are not easy to come by. But here’s the deal: YOU HAVE TO HAVE AT LEAST ONE. You cannot expect a group of noobs to be able to deliver real software under live-action business conditions while at the same time learning. In almost every case, you have to have a strong technical lead to drive the bus, someone who knows the lexicon, business, and process and can put it into an actionable framework such that the hammer swinging noobs can latch on and actually get things done. Missing this crucial resource will cause you immense amounts of pain and suffering. Don’t do it.

Oh, You Mean You Want to Build Software that Actually DOES Something Challenging?

The second scenario where you need business knowledge experts is when you have a complex domain. We’ve noticed in particular that it is very challenging for people to get up-to-speed in complex financial domains, like trading algorithms or complex lending products – and in those cases, we’ve seen it be an absolute <must> for the developer to have business knowledge. It’s easy in those domains for inexperienced resources to get completely shellacked by the domain and just struggle until they fizzle out. The Tech Titans will press into it and immerse quickly. So when you have a complex domain, if it’s at all possible, get a developer who has worked in it before. You will thank us.

The Mythical Man-Month and Other Truths that People Consistently Ignore to their Extreme Peril

The last and most nefarious scenario where you must have a developer/vendor that has business knowledge is when there is a time crunch. So, you’ve already broken the Fred Brooks rule of adding people to a late project and now you still have to deliver. You can’t possibly expect anyone to be effective if they have not worked in your domain before. It just will be a clusterfudge and you’ll end up stealing time from your Tech Titans to train the noob and make your project even <later>. Don’t even think about it. Get someone with business knowledge in your space.

Know your business. Know your lexicon. And get the right people on the bus. Get a Tech Titan.