For the sake of discussion, let's assume the perspective that there are human issues (beyond issues with tools and processes) that create obstacles between the customer and systems development communities. What's the fundamental difference in project vision between these two groups? It’s said that before you can empathize with another human being you have to walk a mile in his shoes. Not having the luxury of cross-training today, let's explore the respective roles of customers and systems developers.

IT Customers Are From Venus
End users and business managers (IT customers) all share common goals: keeping business running efficiently and effectively; to satisfy their external customers; to accomplish both at a profit. Because they deal with day-to-day external customer issues, IT customers are most concerned with day-to-day business continuity.  It is from this perspective that they approach and prioritize projects that are not critical to the mission, including software development.

Developers Are From Mars
Software developers also share a common vision-providing computer resources, facilities, and software applications needed by the business. In this supporting role, the primary focus of the developer’s activities is to satisfy the IT customer by delivering customized software that is specifically designed to their needs.

In short, IT customers focus on the running of the business and its external customers, while developers focus on the delivery of software tools to the IT customers. This difference gives rise to interesting-and challenging-behaviors on software projects. How Do These Differences Affect a Software Project?
Here are a few project activities where such fundamental differences emerge:

·         Software requirements

1.      Venus perspective: Activities that will enable us to do our business better in the future (such as software projects) are secondary to the day-to-day running of the business. The software developers often tell us that they know our business and our priorities.  Why, then, are they surprised when given a choice between satisfying a customer and missing a software project meeting and we choose to satisfy our customer first?

2.      Mars perspective: Since it is the IT customers who want the software, it should be up to them to drive the project. Without solid requirements that are clearly articulated by our IT customers, there is no way that we can guess what problems the software is intended to solve. If the software project is important, then IT customers must allocate the necessary time to properly articulate the requirements.

3.      Achieving Venus/Mars harmony: As with any relationship, understanding the other's viewpoint is critical. When developers say that they already "know the business" it means that they are familiar with the general processes and procedures. It does not, however, mean that they know the detailed requirements to be supported by particular software. Early, targeted conversations to clarify and confirm requirements are fundamental to ensuring the software will support the activities intended.

·         User acceptance testing

1.      Venus viewpoint: User acceptance testing is really a misnomer. We're the "users" and yet the developers keep all the rules about what they perceive to be a "good" user acceptance test plan. We've had a series of meetings among ourselves to find out what they might really be after, but it always seems that we come up short-and then the business priorities get in the way.

2.      Mars viewpoint: The project activities were clearly laid out at the beginning of the project and the IT customers assured us that they would allocate the time and resources to properly "test drive" the system before it goes into production. However, when we took a look at their acceptance test plans, they were a bit of a joke.  There are going to be a lot of latent defects if they don't get more serious about rigorously testing the system soon.

3.      Achieving Venus/Mars harmony: User acceptance testing is a developer term and developers often have a condescending way of hinting that its contents should be obvious to anyone with any business savvy. From the IT customer viewpoint, it would make sense to work together to define what needs to go into a good user acceptance test plan, so that the IT users could then develop one. While all of the permutations and testing combinations might seem obvious to a seasoned developer, the occasional IT customer doesn't know the terms or the test plan development rules by heart. Working together without acronyms blocking the communication will go a long way to having successful testing experiences.

·         Changes during the project

1.      Venus perspective: In business, change is the natural state and we adapt to it as part of our jobs. As soon as we realize that we've missed something in the requirements for the software, we let the developers know. It is frustrating that they often are less than appreciative and even blame us for not telling them about the changes sooner. It seems as though the further we get into the project, the more resistant the developers get about making changes.  It would seem, though, that they would want to deliver software that truly meets our needs as much as possible.

2.      Mars perspective: Some of the changes introduced late in a project could have been avoided altogether if the IT customers would have taken the time on requirements in the first place. The cost to us to make these changes now is substantial. Other (legitimate) changes sometimes come to us way too late-long after coding has begun-and then we might not be able to incorporate them and still stay on schedule. You'd think that the IT customers would know how scope change impacts us, but it never seems to improve.

3.      Achieving Venus/Mars harmony: Again, the solution to the conflict arising over change management lies in clear communication. Contrary to popular belief, many IT customers do not understand the impact of change that is introduced late in a project. Like the frustrated construction manager whose customer insists on adding a second kitchen that was missing from a floor plan, developers get frustrated when IT customers don't participate in the requirements phase, but later demand that changes be made after construction (coding) has commenced. In many IT shops, an early discussion between IT customers and the project team about the exponential cost of change (a change costs $1 to make at the requirements phase, $10 to change it after design, and $100 to change it after coding) has illuminated the issues concerning change late in the lifecycle. Understanding the effect of when a change is introduced is as important as the change itself. Ultimately, it can lead to improved software quality and better relationships all around.

Summary
These examples illustrate common occurrences on software projects and suggest preventive actions to reduce their impact. Without a solid relationship, the partnership of developers and IT customers can deteriorate into sides, which causes software products to miss the intended mark. In the universe of software projects, if Mars and Venus are out of alignment, the entire solar system is disrupted.