On Needs, Wants and Being Told What to Do

Brace yourself. 

This is a bit of a rant.

For most of my 30+ years in software development, many of them have been working with companies where software is made to support their primary business. It might be Insurance or Manufacturing or Sales or Distribution & Transportation - but many of these companies, the people using the software don't pay for it. They really don't have an option. To do their jobs, they need to use whatever stuff they get from IT.

If this does not describe the type of organization you are working in, you might want to skip this. Of course, if you have worked in an organization like this, or might possibly work in an organization like this, or perhaps you're curious what has me so worked up - please read on. Thanks.

Sometimes IT people annoy me. Of course, sometimes Internal Business folks annoy me, too.

How often have we heard or heard about IT/software development folks, telling people in business units what they need from the software to do their jobs?  After all - the IT folks know what the computer systems do and can do and so they are the experts.

Sorry.

The accounting and finance courses I had in school, longer ago than I want to admit, while it helped me work through and understand journal entries and balance sheets and other basic finance and accountancy stuff - These do not give me enough understanding to tell the Chief Financial Officer or Company Treasurer or whatever, what they need from the software their staff uses in order to make good, informed decisions.

I can, however, discuss with them the intent they have for using new or changed software. I can discuss the gain they hope to achieve from said software. I can listen and take into consideration what their desire for the end product should look like.

When I am working on making software do something, I can do something else to help the people who need this for their jobs.

I will do my level best to make software and work with the team making the software, that fills the needs and purpose described and discussed.

When possible, I will do my level best to have it work as they wanted.

However - that is not a promise.

Instead, I will do my best to fill their need first.

I've learned that IT people see their "wants" as "needs" (rather like the "business" folks they make software for.)  Cool features or functionality are cool. They are pleasing to design and implement. Do the help the people they are intended to help? Sometimes, sure. Of course. Other times? I've seen too much time and effort put into something that business functional experts truly do not care about.

And what of the "Business" experts? 

The people who use the software every day to do their jobs. The people who make use of the results of that work, every day, to do their jobs. The "decision makers"  looking at reports or summaries or dashboards produced and built by IT - What about them?

Do these people understand the business rules the software is intended to follow? Do they understand what the software is intended to do and why? Do they understand the purpose of what it does now and what the change will be?

Do they understand or know this without asking IT folks for help?

When they do, can the IT folks help them without looking at the code?

Have people abdicated their responsibility and put others in place as their proxies?

Now, if these things sound familiar in your organization, is it any surprise that your software has problems?

None of us really like it when people with no clue what we need tell us what we should do next.

Do the people who are supposed to:

• Understand the purpose behind the changes;
• Understand the business rules that to be followed;
• Understand the why behind these things;

Who is to blame for IT telling people what the changes will be and what the software will do?

Someone has to decide what it will do. I suggest it be someone who knows what the purpose and needs are.