This is especially troubling given the growing strategic role of software in the enterprise.

Very smart people are planning and executing these projects. Why are they struggling? Why is it that when business people and technologists collaborate, bad things seem to happen? Are we speaking different languages? Are we trying to accomplish different things?

Are IT people and business people from different planets?

The Situation

Kenton, a product manager and business partner, has a new idea to market his application: integrate a referral program to incentivize users to recommend the product to friends and family. He also has some specific ideas about how to implement it within the current application.

Kenton gets together with Ryan, the development team lead, to discuss his idea and the changes that would need to be made to the existing application.

Kenton feels like this is a quick and easy win for the business. That is, until the two of them get together.

The Face-Off

Kenton: Hi, Ryan. I have a great idea to expand our customer base. I would like to get this out with the next release, so I’ll shift the priorities for the team. I’m going to put this at the top.

Ryan: That sounds great. What are we doing?

Kenton: Well, it should be pretty simple. We want to do a referral program so our existing users will get their friends to use the app. I’m thinking all we need to do is just add a page that lets the user enter the information for the person he wants to refer. Then once the new user signs up, we’ll credit the person who made the referral and give him a free month of access.

Ryan: Wow, I’m not sure we can get that done before the next release. This will probably take a couple of releases.

Kenton: What? It’s basically one page with name and contact information!

Ryan: No, there is so much more to it than that. We need to add the data to the warehouse. We need to build a notification engine that notifies the person who was referred. Then we need to build a credit system, figure out the different flows for users who are logged in versus users who are not logged in, and add some sort of link to this referral page throughout the application. And then we need to build some way to view and manage referrals. We have to build in security so people don’t scam the system, and, of course, we have to validate that the person being referred does not already have an account. And finally, we have to tie this into the billing software so it knows to credit the users when they refer someone. This could be huge!

Kenton: No, all I need is just need a simple page with name, contact information, and a link on the main page. This should be easy.

Ryan: But how are we going to inform the people of the referral? How will we issue the credits? We need to load test this. You’re going to want to customize the page, right? So it will have to be dynamic and use our content management system. This is not going to be easy.

The Resolution

Ryan: This is either bigger than you’re thinking or we are not on the same page as to what we are doing. Can we back up a minute and just talk about why we are doing this and what it is you need to accomplish?

Kenton: Sure. We need to build a pilot program that will allow us to evaluate the return on investment for a referral program. All I want is a simple referral page and a way to report who is giving referrals and who is getting referred. I’ll run the reports. Marketing will handle the notifications and finance will handle the credits. If everything works, then we’ll probably need all of those things you talked about. But for now we just need a simple page that records the data.

Ryan: OK, that makes more sense. I didn’t realize you were just looking to run a pilot. So, yes, we can certainly build something quickly that looks good, but remember, it will require manual processes to support the system. We should also think about how to measure the success of the team as well as the success of the project. And let’s also talk about the data points that will help us decide when we need to automate things like notifications and credits. Because we don’t have anything like that today, it will take awhile to build a system that supports those things.

Kenton: That would be perfect. I’ll work with the reporting, finance, and marketing teams to make sure they can handle the extra workload for the pilot period.

Ryan: Great. I’ll talk to the UI/UX team to get a design and get an estimate from the development team, but this shouldn’t be a problem. I’ll also need some of your time and input. Would that be OK?

Kenton: Sounds like a plan.

The Wrap-Up

Does this sound familiar? How often have you jumped into a project without understanding the true business objective?

When you find yourself in this position, try asking yourself, “Why are we doing this project?” or “What does success look like?” The business needs to have clearly defined objectives, and it is IT’s job to understand those objectives. Only then can the two work together to find the right solution (and avoid IT crafting a solution based on their own assumptions).

When projects fail, it’s rarely because of complexities around technology. Most often, it’s because of the human dynamics between business and IT.

Most of us have jumped into projects either not knowing or losing sight of why the project is being done in the first place. This can lead to misalignment between what the business needs and what IT builds. Before starting a project, you should always have a clear idea of why and what. Only then should you begin to start solving the how.

The business side should always have a business case that explains why a project is being done and its success criteria. They should also have a clear understanding of what they want the new system to do in order to accomplish the objective. Without this information, the project may be doomed from the start.

IT leaders need to make sure they fully understand what the business is trying to accomplish as well as what success looks like for their own teams. Without a clear understanding, the IT team tends to fill in the gaps on its own. This usually sets the stage for failure.

Only after there is a clear understanding of why a project is being done can a solution be built that accomplishes the business-defined goals. This requires a partnership between the business side and IT.

So the next time IT says a seemingly simple change is an enormous amount of work or a business representative is frustrated because that button at the bottom of the page will take two months, take a step back. Revisit why you’re doing the project in the first place. Make sure both teams are aligned on the why and the what of the project.