You can logically argue that software requirements save time, save money, and increase the return on your technology investment. I believe all these things to be true, not because I’ve done any quantitative study, but because I’ve directly experienced it in my day-to-day work. But I’d like to focus on what brought me to the business architecture/analysis profession and one idea that is steadfastly holding me here.
I believe that good requirements make the technology shop a better place to work and make that work more fulfilling for everyone involved with technology.
What causes low morale on technology teams?
If you are a leader in any business or organization, then you probably understand that part of your role is to help others find fulfillment in their work while at the same time generating business value from that work. I learned this a few years back while reading James Autry’s book titled The Servant Leader.
Few developers on a technology team are fulfilled in their work when they deliver a brilliant piece of code that no one ever puts in production. No product managers are fulfilled when they wait 2 months for that perfect feature that would generate more revenue only to have it miss the mark. No software tester is fulfilled when they find every bug in the code, ensure it’s fixed before release, and then hear someone from the business say “it doesn’t work”. These are not positive situations for your employees. They breed discontent and distrust.
Leadership can support alignment between business and IT
The alternative is to be an advocate for two accountabilities within your organization:
- Aligning your business team around what is to be built. And this means everyone: marketing, product, sales, customer service, and finance.
- Aligning your technology team around a solution that solves the business problem and delivers real value.
Yes, it can be a difficult process to gain alignment on requirements and project outcomes and to make the time up and down the organization for the collaboration and reviews necessary to create this alignment. But, creating focus on these two accountabilities can create a waterfall effect within your organization of clearly defined work directly tied to business value. These are the spheres within which the best business architects/analysts, project/portfolio managers, enterprise architects, and development managers are their most productive. I am proud to take on these challenges not just because they create value within organizations (although they most certainly do), but also because they help create better places to work.
So, if you’ve put off this challenge within your own organization or just hoped it would solve itself, take a hard look at the impact it’s having on your employee morale, productivity, dedication, and motivation.
It has taken ages for top management to understand software as a strategic asset. IMHO, They tend to focus on increasing revenues rather than reducing costs. So increasing productivity has always taken a back seat to sales and marketing, both in mindshare and funding. YMMV.
Another problem is ego. Everyone wants to be the hero, and no manager, top, middle, or other, wants some upstart individual contributor and/or IT department to take the spotlight. The decision makers don’t have the time to understand the problems, and the analysts don’t have the power to make the decisions. But everyone has the power to be obstructionist and resist change (please don’t attibute that to me).