Venus and Mars in the Workplace

[article]

·         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.

About the author

Carol Dekkers's picture Carol Dekkers

Carol A. Dekkers is President of Quality Plus Technologies, Inc., a management consulting firm specializing in creating peace of mind for companies who want to improve their software processes. Software measurement, software quality, process improvement, requirements, and software sizing (using function point analysis, as an example) are a few of the Quality Plus areas of specialization.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09