Many years ago, I subcontracted on a large software project. It was an automotive warranty claims processing system. Many consultants had cycled through this organization over 3 or 4 years, none ever seeming to make a dent towards completing the project. I personally spent eighteen months on this project. Rumor has it that almost $30 million was ultimately spent, with little to show for it. Yes, you read that correctly.
How do unproductive projects fester like this for so long, and with such expense? I noticed a few behaviors that contributed to failure, and over the years, I’ve seen them time and time again. Do these sound familiar to you?
Unclear Objectives
I’ve seen dozens of projects fail simply because nobody knew why they were working on them. It may seem obvious that anyone involved in a project would know why they are working on it, but this often isn’t the case over time. Competing objectives at the executive level tend to morph a project from trying to satisfy one objective to many. I’ve also seen ambitious executives use one project to try to “sneak” another one in under the radar. This has the net effect of fuzzy goals, scope creep, and lousy technical design. Timelines inevitably slide, nothing ships, and morale suffers.
Constantly Changing Requirements
After over two decades in software engineering, I am still amazed when I see project requirements changing often, yet every other variable is held constant. That is, you are given a deadline, a set headcount and budget, and are told to “make due” when requirements change every other day. This is a recipe for failure and burnout, and it’s unsustainable. Something has to give, and it’s usually quality first.
Vaporware
Your sales team is presenting at an industry trade show. A senior executive of a Fortune 500 organization they have been trying to land stops by for a demo. She is dazzled by what she sees, and the sales team promises not only the moon and stars, but also delivery in eight weeks. There’s just one problem – the product doesn’t exist yet. Now your engineering team is tasked with innovating on a deadline. This is known as “vaporware.” To make matters worse, the CIO hasn’t been consulted on matters of budget, priority, headcount, or complexity. But the CEO sees dollar signs, and orders the troops to “make it happen.” What could possibly go wrong?
Overengineering
We’ve discussed scope creep. This one is a little more insidious – scope seep. That is, features, functionality, and other complexity introduced not by the client, but by the engineers themselves. Many engineers are tempted to “gold plate” their solutions with fancy methodologies, standards, or technologies, with the intent of maximizing quality. While this is well-intended, it tends to inflate projects in both time and cost. Now, I’m not suggesting we abandon proven approaches, but we must remain practical and flexible…we must be agile.
Agile to the Rescue
I work with clients to deliver software in as little as 30 days. I don’t mean a canned demo. I mean working software. We achieve this through agile practices which address the symptoms I mentioned above. We start with clear objectives – the business outcomes you seek to achieve. Then we establish the metrics by which that success will be measured. Therein, we will discover value. Using the objectives, metrics, and value as “guard rails” for a project, we are free to embrace changing requirements, avoid the trap of vaporware, and deliver just the right amount of engineering to ship software early and often.
Challenge Questions for Business Leaders:
- How many of your projects have failed over the years due to one or more of the above reasons?
- Are you able to easily accommodate changes, manage risks, and lower expenses for any given project?
- How quickly can you respond to market demand for new features?
© 2015 Mark Richman. All Rights Reserved.