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.
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:
- Plan better
- Buy smarter
- Succeed with projects
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.
When there is confusion, confidence falls apart. Complex projects stall. Morale implodes. Churn follows.
As a Business Analyst, my mission is to provide a clear, prioritized set of requirements that communicates to many audiences: Stakeholders, Designers, Developers, Testers, and Technical Writers.