In my last blog post, I talked about how in some ways, the quality of software requirements can mean more to a project’s success than the skill of the programmers themselves. I also talked about how merely utilizing business analysts may actually make the problem worse. But what can we do about it?
Programmers need to know the product as a whole
Software projects that I’ve been involved in where the programmers had a thorough understanding of the business need to be addressed were significantly more likely to succeed than projects where the programmers were given a set of specifications to complete. Full stop. There is a belief among many business and technology leaders that a programmer’s time is best spent writing code, but so much of what a programmer actually does has little to do with code. Every day software developers must make decisions about when to spend the extra time to make a system flexible, where to spend time making the system extra secure, when to rethink design assumptions, where things may be simplified to realize cost savings, etc. Programmers who know what the software is trying to accomplish will make better decisions and will ask better questions. Programmers who don’t will not, inevitably leading to problems down the road.
Business leaders need to know what’s possible with technology
Unfortunately, many business leaders choose to “leave technology to the technology experts”. This is exactly the wrong approach to take if you want to have a successful software product. In nearly every one of the extremely successful projects I’ve seen, at least one business leader was actively curious about how and why we did what we did. The benefits were twofold:
- Business leaders who have an understanding about what’s easy and what’s difficult to do with technology have better suggestions about how to accomplish their business goals at a low development cost
- Business leaders who understand the compromises that occur during software development tend to be much more understanding when problems arise, leading to faster problem resolution
In general, the more overlap of knowledge that exists between the development team and the business leadership, the more complete the communication and the better the software product.
When possible, let business stakeholders customize and configure the system themselves
There are two primary ways I’ve had success getting business users involved in software projects. The first, especially useful when customizing a purchased system, is to give business users rights to customize the system themselves. The typical interaction here is to have IT take ownership of the implementation, partly because IT wants to feel relevant and partly because the business stakeholders don’t have time to get involved. But when the business stakeholders can get their hands dirty, so to speak, they have a greater sense of ownership over the project, leading to faster progress and letting the technologists focus on bigger-picture issues.
The other way I’ve had success with getting business users involved in software implementations (both purchased and custom software) is to give users (controlled) access to the data for their own reporting. Most reporting software is relatively easy to learn and use, so there really is no good reason to have software developers create simple reports.
If you hire an intermediary, hire a subject matter expert
In my last blog post, I had discussed how having a business analyst on a software project often makes requirement quality worse, not better. This is because business analysts that merely reword business requests in the form of business requirement documents unintentionally distort business goals. What about Subject Matter Experts (SMEs)? I admit I haven’t seen this work in person, but I could easily see a situation in which a true SME, adds value as a go-between for the development team and the business stakeholders.
I’d like to emphasize that there is no substitution for getting the software team and the business stakeholders working directly together. It improves communication, enables better decision-making (on both the developer and stakeholder sides), and leads to better overall satisfaction for all participants. Yes, I realize that this isn’t easy to do in many environments for a number of reasons. But do you want to let people stay comfortable, or do you want your software projects to succeed?
This article is published as part of the IDG Contributor Network. Want to Join?