One day I was reviewing a list screen in the development den and hit a brick wall. The application queue page had been developed by the senior architect of the team, a bearded philosopher type who had deeply absorbed the agile mantra to ‘maximize the amount of work not done.’ For this fellow, the answer was automatically ‘no’ until you made your case. I’m sure you’ve met one or two of these in your travels.

The screen in question was a list of transactions and they had some common attributes. That is, multiple lines could have the same description or the same type. Anxious to make what I thought was an easy improvement, I suggested that we add a ‘Row’ or ‘Item’ number column – something that the user could click on to open that row. The architect insisted that any other column could be used for that. A new column was not needed. The identifier column was indeed added to the list, but not that day. That day I left the room with hurt feelings and an important lesson in hand.

I failed to make the case for the new column. The change seemed logical to me (and, in fact, was) but I approached the feature based on my own desire and experience rather than bringing the team a value-based User Story that carried the weight of a real stakeholder. It is a lesson I would repeat until I fully embraced the principle that development team members are not application stakeholders. Only the voice of a real customer carries authority in a feature User Story.

Have you ever had the sick feeling of being held hostage by an outside expert? Perhaps you felt helpless that you couldn’t regain control of your project. Maybe you felt angry because the budget kept creeping upwards. You probably wanted a project-sized “undo” button!

In the course of a technical career spanning more than three decades, I have asked customers pay more than they expected for products that I delivered. They felt a bit ‘taken’ and I felt bad for putting them (or allowing them to put themselves) in that situation. We can find ourselves in this mess for a number of reasons.Are you being held hostage by your technologists? Click To Tweet
Technical people tend to underestimate projects. It’s not that they don’t want to be accurate, but rather that estimating a complex project is difficult. It often feels more like a black art than science. I’ve seen it done well, fair, and poorly but I’ve never seen it done perfectly. Most experts agree that estimates are almost always wrong.

Another factor is impatience. As engineers, we like to give customers what they want right away, so we tend to rush the process. There is also a natural fear that if we don’t trim our bids to the bone we will not get the business. The net effect is that we sometimes disappoint customers later by failing to meet deadlines. Schedules slip and costs increase because development takes longer than planned.

Then there’s the whole client management challenge. We should always manage a customer’s expectations so that they are not surprised, but explaining to them that something they want will cost more or is “out of scope” can feel like intestinal suicide. We are not all people-pleasing cowards, mind you, but it can be very difficult to disappoint people. Avoiding confrontation, of course, is a great way to create unhappy customers later.

In addition to being the provider, I have also bought software, websites, and other technical products produced by others. I have been a victim and I know firsthand the pain of cost overruns, disappearing vendors, and shoddy workmanship. By and large, the vast majority of technical people you meet will have good skills, a genuine desire to please, and reasonable prices. That doesn’t mean that your project will succeed. As a buyer, you have a big part to play in creating a favorable outcome.

My hope is that the scar tissue that produced this article will help you to:

The enemy in software projects is Complexity and the beast wields a wicked mace called Change.

Our goal is Confidence — in the future happiness of our customers, in successful test results, in modular code (yes, I am going backwards through the SDLC), in the stability of the requirements, and in the surety that our delivered work will serve its desired purpose.

Our most effective weapon in this fight is… Clarity.

There are many approaches to delivering software. Some claim to move faster than others. Some claim to be more thorough and less prone to rework. Regardless of the methodology chosen, the team must achieve and maintain Confidence about what they are building, how it will be assembled, tested, deployed, trained, and updated.