Gary Allison's Leadership Blog

Found this entry on Guy’s Blog and wanted to cite this here. You have to love what you do. Without passion, great success is hard to come by. An entrepreneur will have tough times if he or she isn’t passionate about what they’re doing. People who love what they’re doing don’t give up. It’s never even a consideration. It’s a pretty simple formula.

Talking about requirements makes people’s eyes glaze over, so lets ask a more poignant question. What market are we trying to win? This focuses our vision in a much more effective way. The first deadly sin of software projects lies in not asking this question. Requirements management is a fundamental necessity in software development. Changing requirements causes obvious schedule impacts but has more subtle impacts in quality of the product and maintainability of the architecture. But, lets face it, few systems worth building have all their requirements known up front. There is always some element of discovery as the business matures, as early customers give feedback, as new deals are brought to the table.

The deadly mistake that can make your software project, and even the company, fail is a lack of focus on precisely how this product will win in the market. To answer this question, this presumes we can answer these questions of precisely which market are we in, who are our competitors, what are the major technology movements in the market, how will the product be marketed and sold, how should it be priced, and who will buy it. Even if you are the “technology” guy in charge of the software project, you need to know the answers to these questions because it affects in important ways the requirements of the system.   Most companies start out with a pretty firm grip on how they plan to win in the market. What trips them up time and again is not realizing the answers are changing. The deadly sin here is that if the answers to any one of the questions above change over time, they can dramatically affect your requirements and ultimately lead to the failure of your software project (and the company).  These changes can take place very quickly and very subtly in a small project. For example, selling a product into a new channel or to a new type of customer can quickly mushroom into a set of new requirements that can crush your existing commitments. To mitigate this, it is essential that the product management team and development leaders be integrated into the sales processes to gain visibility into these opportunities so they can anticipate new requirements as early as possible. This can be difficult as everyone is excited about the new customer or opportunity, and many times it becomes a “peeling the onion” exercise. At first, it seems that the new customer only needs a small change to the product, and then another, and then another. These changes are driven because they are fundamentally a different customer than has ever purchased before. Recognizing this difference is crucial.   

Another good example I’ve encountered many times is the difference between reseller and direct customers. Resellers are extremely valuable sales channels, but have very different requirements in products and billing than do direct customers. It is important to recognize and understand these differences up front. A reseller may want to embed your product in theirs or rebrand your service / web site. They often want to hide the visible aspects of your product because they want to present only their brand to the customer. These features must be factored in up front as they are very expensive to retrofit.

Finally, the new customer may not necessarily drive changes into your core product, but rather may require you to drive changes into your core processes. For example, a telco customer may have very long cycles between applying updates and may require different service levels that your other customers. Each of these have a cost component associated. The longer upgrade cycles may mean you have to keep alive older branches of source code alive for emergency patching, along with test environments that support that branch. These kinds of patches can be very expensive both to you and the customer. Also, you may have to go through longer or additional test cycles for the releases that go to these customers in an effort to avoid these costs.

In conclusion, asking “What market are we trying to win” means understanding the answer to the question and measuring each sales success against that answer. If the sale represents a fundamental change to this answer, then take the steps to deliberately plan for the product and process changes necessary to deliver on the opportunity.

In our examination of reasons why software projects fail, we start with a few basic assumptions. These seven deadly sins of software development assume that many of the fundamentals are in place: the team is staffed with trained experienced developers, you have a modern source code control system, build processes, test methodologies and automation, bug tracking system, project management systems, etc. In essence, we are assuming at least a CMM Level 2 team – without at least this level of process maturity, there are many other opportunities for the project to fail. This series of short articles focuses on the set of issues that sneak up on experienced software developers and development managers. They are seemingly common issues, but can surface in subtle and surprising ways while teams are heads down implementing a project. We’ll examine some examples along the way as well. Although we may have to change a few names, they will be real examples drawn from experience.