This isn’t what we asked for!!! We built it using your requirements!!!

I have experienced constant struggles between the business units and IT departments at work.  A businessperson feels they have been very explicit on what they need delivered regarding an IT solution to a business challenge.  The IT person feels they have captured all the relevant business requirements to deliver a great solution to help with business needs.  The solution is implemented and nobody is happy.  What just happened?


Unfortunately, I have been on both sides of this argument and there is no easy answer.  However, I think there is one constant that can help improve the quality of any IT project.  It starts and ends with relationships.  People have told me that it is all about the process.  “Plan the work and work the plan.”  As with any plan, pressure mounts due to time constraints.  People try to get through tasks to capture requirements, processes, testing approaches and etc.  People talk and share when they trust you and you take an interest in what they are doing.  Not only is it important to build these relationships within the project team, but also outside the project team.  Usually, a project team is asking a person to give more of their time in addition to their current role.  Knowing this, the project team needs to be as efficient as possible when capturing data and knowledge.


In the first article, How to Get Down with the IT Guys the author talks about how people with curiosity about the “other side” tend to make greater strides because they ask better questions.  I agree with this as well.  It puts a person in a place to ask why something has to be a certain way and gives people an opportunity to challenge themselves to see if something can be done differently to accomplish the ultimate goal.  In the second article, Building Relationships in Project Management, the author talks about knowing who the stakeholders are and managing their needs and expectations.  When running or working on a project, it is more than managing the tasks and timelines.  You have to manage and lead people.  These relationships are what lead to successful projects.


Where I work, the company has made a conscious effort to move business folks into the IT department to help with these relationships and to deliver improved solutions because business requirements are better captured.  In my opinion, the business experience has helped, but the relationships these people have throughout the organization is what is driving the improved success.  People are more comfortable with those they know and can converse with in the same “business language”.


I am curious to hear what measures your companies have taken to overcome the barriers between the business and IT departments.  In your experience, are there certain communication practices that work better than others do?  What are some of the processes your company uses to capture business requirements?

7 thoughts on “This isn’t what we asked for!!! We built it using your requirements!!!

  1. My company faces similar types of issues mentioned above. In an attempt to help create a better relationship between IT and traders, our company has recently hired some of the outside IT specialists as full-time employees. I believe the hope is to help the IT staff to better understand the needs of the traders and also get the traders to better understand the abilities of the IT staff. Perhaps, as Jeff stated, build a better relationship between the two groups within the company. I like the idea of moving business people into the IT department since I believe these people can be a translator at times. I believe my company has a long way to go in order to better the relationship between the two groups, however by hiring more in-house IT staff I believe this gives them more opportunity to work with other business units within the company to understand software requirements and forecast accurate project timelines.

  2. My company is certainly not immune to these sorts of issues. One tactic that’s worked well is having members of IT spend time shadowing other employees while they work. I think it definitely helps when the “why” that’s driving a particular request is understood. If IT understands the challenge and sees how it affects the workflow of a given employee or department, they’re better equipped to come up with a solution. The person experiencing the issue and requesting the change may not always have the best vantage point for finding the fix. Obviously time constraints often require decisions to be made quickly, but soft releases and beta testing are obviously beneficial if they allow glaring issues to surface prior to a mass release.

  3. Great articles and summary. I also see this a lot at my work and our company is just now starting to cross train employees to help gain a better understanding of both the business and IT sides. I agree that properly managing the needs and requirements of the stakeholders is critical to the relationship between business and IT. Often times I’ll come across IT projects that involve implementing tools or applications that were not requested by the stakeholder and are considered to be over the top. The business/IT relationship is a crucial one in many companies and the management and leadership of people is an important aspect of the overall relationship.

  4. One change that my company recently implemented in order to streamline communication between the business side of the company and IT is to relocate our IT call centers from India to the United States. For years, associates complained that the language barrier between IT and the general population was a major obstacle. Although IT associates in the United States may be more costly, problems seem to be solved faster with less aggrivation which makes the added cost worthwhile.

  5. Very interesting (and very relevant) topic. With the surge of digital solutions in just about every company, this becomes more crucial than ever before. Also, to save costs more and more companies are hiring vendors to complete projects, and these vendors very often are overseas. The combination of these two things have created a riff between IT/engineers and business stakeholders. Communication can be more difficult, which in turn creates a misunderstanding of project requirements. I agree with all of your comments that the most successful businesses make sure to integrate IT with the business side so that everyone better understands the bigger picture. More transparency means more understanding and a better overall outcome. Good communication comes along with good relationships, and vice versa.

  6. Jeff, I do not have similar experience in my company as far as internal projects but instead I see similar results with our projects to external customers. Usually, although following all the requirements, the results do not please the direct users and it creates great friction and discomfort.
    The reasons I could identify so far are all related to lacking of involvement of the right people and when the right people were involved they just did not participate at all as they should have.
    In general, people who are going to be the specifiers and end users are too busy with their daily activities and just do not see how they can add more work into their already busy days. Consequence is usually less than satisfactory results where developers and project team put a lot of effort on what they thought was best but not at all aligned with what users really needed.
    On the other hand, when project team, which included developers, specifiers and final users all exclusively allocated to the specific project and without concurrent distractions, results were excellent and final users attested high satisfaction and business aligned results.

  7. I agree with the comment above about IT staff being required to shadow employees. My last place of employment actually did somewhat of the reverse. They often hired people with operational experience in a particular business unit to work in IT and train on the complexities of SQL and server management. These staff members therefore functioned as liaisons that were able to ‘translate’ the needs of the business unit to the IT team. Also, upon completion of a project, SLAs were signed by both parties to assure acknowledgement of future responsibilities.

Leave a Reply

Your email address will not be published. Required fields are marked *