I lived as a CIO in this type of environment for almost 8 years before I said goodbye. Our CEO, who would not even have a PC on his desk, demanded the users were kept happy. My mantra was "What is the problem we are trying to solve or opportunity to exploit?" Invariably, users would only give us the solution, never the requirements. If we dug our heels in and said, "If you can't explain the problem that needs fixing in 25 words or less, than you don't understand the problem" I could expect a call from the CEO. If my department, however diplomaticly, suggested that the user solution was off base and we could help them find a better way, they went whining to the CEO about IT not being "responsive". We became executors of orders, rather than a source of innovation. The collective knowledge of my department was an untapped asset at my last employer. The CEO supported a hostile attitude tworads IT that I tried to change for 7 years before quitting. I was told we (IT) were a service organization not unlike cleaning services and our job was to give the user what they asked for regardless if we thought it was going in the wrong direction. I once told the CEO I would work for free and take one half of the savings my department could document with our ideas. He laughed. The user community knew what they needed and we should make them happy. One of my C level peers even started a movement in the company to do away with passwords and user IDs because it took to long to sign in.(This was a healthcare organization subject to HIPAA regs). The idea actualy got traction and I had to defend the requiremnent at a management meeting. Take orders and not participate in the thought process leading up to the solution....never again.

Wow, hence the need for BPMS products. I have worked on both sides of the house and totally understand the frustration being expressed. The bottom line is there are very few truly good managers in corporate America. There is far too much fear and ignorance in leadership and finding folks on either side willing to cooperate with the other is diffucult. Within my current role as a Senior BA I see it as my job to bridge the gaps being discussed here. Business and IT speak 2 different languages and something or someone must provide translation. Just as there are a limited number of people who can translate effectively from Chinese to Russian there are a limited number of people who can blend the language of business and IT without putting both sides on the defensive. This is a problem which needs to be addressed in mass and the skill sets don't exist in mass. Hence the help of BPMS. These products provide many benefits for the issues at the root of the problems. The business is forced to define their process and with the use of the simulators bottlenecks, backlogs and inefficiencies are readily exposed with no hiding under or behind anything. There is real accountability in the analizer and optimization in these products (the good ones anyway). What does IT get from all this? A separation of the what and the how. IT gets to move toward a SOA architecture. IT gets to have control of the backend. IT gets to be the hero because it doesn't take forever to provide enhancements. (Savvion is on time and under budget a whopping 93% of the time!) Requirements become process changes which must make logical sense or they fail in simulation. None value added steps are easily exposed when the model is created. Is this a magic bullet to save corporate America? No, not all problems will go away and poor management will always exist. What this will do is put everyone onto the same path again, working toward the same goals and provide a method for collaboration. The power struggle has to stop if companies want to be around in 10 years. It truly is taht simple. Either everyone starts working together or no one will be working at all.

Gathering requirements or taking orders is an excellent question. Most organization believe that requirements are what they want to happen. If they state they need a report, they believe that is a requirement. Most IT organizations will not take the time to work with the customer to figure out what the requirement is. As a business user your motives are not to mess up IT and make their job harder, you are looking to solve a problem you have. If you were assured the problem would be solved with the new system but it was not, you tend to stop giving requirements and start giving required solution. Or if something you asked for doesn't work the way you need it and IT tells you that was your requirement, you stop giving requirements.

When a customer tells us he has a requirement for a report, we tell them it is not a requirement. A requirement is to have this particular information provided at this time. Then we can review the possible alternatives to meeting the customer requirement. Understanding what the customer's business need is time consuming and difficult at times, we would rather jump into coding the solution.

However, a larger more difficult problem is the communications between the business and IT. IT wants the business to talk in term of there processes and what the processes are accomplishing. They want them to detail every possible "requirement" for their activity. This is totally unrealistic no one can pre-define with today's tools all the requirements that have for a given function. The business deals with "things"; parts, people, purchase orders, invoices, events, etc. If you want to effectively talk with business talk about the things they care about. Then understand what they want to achieve. Forget technology, they don't (or shouldn't) care. Just solve their problems.

If they need customer information for a particular marketing program they want to initiate, how can you support this requirement? Expect change, if they don't get enough customer using the criteria they established -- of course they are going to change the requirement. It's not a plot against IT it's running the business. The operations of the business will always take precedence over the comfort of IT.

If the current IT methodologies or processes are not working to support business than we need to consider changing them. Create a common view or shared perspective with your business users, then work to giving them the tools they need. Forget the complaining about the poor requirements or the giving of orders, find ways to talk their language and help them operate the business.

An order taking environment reveals the maturity of the IT organization. Moving to a business problem-solving approach requires discipline and leadership within IT to drive a process that properly defines the problem or opportunity first.

When engaging with business partners to kickoff off a new project, I start the engagement by completing a template that describes the business problem or opportunity, what the impact is, what is the urgency, the root cause, and expected benefits. This approach helps to drive focus on the business opportunity and requirements so all project stakeholders understand the mission. Once this foundation is set we move on to understand the business process requirements and steer clear of specific design issues or solutions. Otherwise, the process is tainted and IT is driven to the answer by the business.

When I started driving this methodology within IT, my business partners struggled at first and it was interesting to see the dialogue as a result of this approach. Much of the dialogue was driven by business partners clarifying what the real problem or need was. My guidance is to never skip this step before understanding the detailed requirements. This will help to improve the credibility and effectiveness of IT by taking a consultative approach that focuses on driving business value. It will also insure that all potential solutions are identified by IT that may not be obvious to our business partners.

An effective IT organization must create a business-savvy culture that understands business needs, requirements and recommends IT-enabled solutions to drive value. The IT organization must be organized to facilitate this type of consultative approach. A recommended organization design is available on my blog at http://jamesgray.typepad.com/innovate/2007/06/optimizing_the_.html.