2011 Issue

47 H Igh-PRoFILE SoFTWARE FAILURES occa- sionallymakethenews.InCaliforniathis year, Marin County’s Board of Supervi- sors voted to stop a five-year-old $30 million software implementation and seek an entirely different solution. Further, they presented a lawsuit against their service pro- vider to recover damages in full, alleging the faultbelongedentirelytotheserviceprovider. An interesting survey of lessons learned, drafted by Marin’s Information Services & Technology Department, sheds light what would have helped the project succeed: “IST involvement up front to guide the steering committee of employees from key departments in recommending a systemand leading its implementation” “An incremental, phased approach […] rather than the ‘big bang’ approach” “Regular status reports and meetings” In my experience, engineers or executives who rely on the services of software de- velopment teams fall into two categories: those who are experienced working along- side software development teams, and those who have yet to learn. Unfortunately, Marin County indicates they are the latter. This is an important distinction because effective software development is anything but intuitive, and without knowing what leading indicators to watch for, you may be participating with, or even contributing to the demise of your own projects efforts. In my experience, most software develop- ers are dedicated enthusiasts who want to build a valuable and well-accepted solu- tion for their sponsors. As with the Marin County case, project failures are often the result of gyrations caused by an unassum- ing and inexperienced sponsor working alongside the development team. If you are working with a software devel- opment group, here are some things you can do to minimize the chances of your software project failing. Before you engage First, realize that the proper perspective both groups should have is that both of you are working collaboratively to develop the best solution — and not that the soft- ware team is there to do your bidding. Together, you can build a useful and timely solution, but there needs to be a concerted effort, and some planning and discipline on your part. Listen to your software team when they request time and budget for project plan- ning. As a consultant, I occasionally hear a client say, “We don’t what to pay for project management or documentation, we’ll just tell you what to do as we move along. ”This is an absolute recipe for a disaster. If this is your thinking, expect to end up with an unusable deliverable, or an out-of-control budget, or probably both. Before you engage your development team, be sure to have your objectives and deliverables decided upon and describ- able with enough detail that you will not be changing your mind midstream. One of the largest hidden wastes in software development is the sponsors, or users, changing their minds midstream about what should be in the product. Software development is sometimes described as an iceberg, with that portion you see on the screen representing 1/10 of what is actually present. Asking developers to make drastic changes to an application midstream requires exponentially more effort than what is visible. An additional problem this causes is the architecture fidelity becomes compro- mised, and this is the first step towards Dancing With Your Software Team Mike J. Berry, PMP, ITILv3, CSM, CSPO It’s easy to talk about failed software projects. With the software industry now 50 years old, and over $300 billion invested annually worldwide, there is quite a bit of it happening nowadays. architectural degradation, which leads to an eventual mess of spaghetti code.This is important to you because the more the initial system architecture is degraded, the greater the time and cost requirements will be to add future features to the product and performadequate testing on the prod- uct. In extreme cases, excessive systems changes over time degrade the application so much that it must be replaced. For the same reasons, it is important to give yourdevelopment teamenough time tocom- plete theobjectivesas theyare issued. Youwill have better synergy with your development group if you reviewtheentireconcept initially, then focus on themost important objectives, one by one. Give your programming team time to complete each component before mentally taxing them with extreme detail about future components. Finally, at the start of a software project, an efficient approach to delivering software value to those who need it most is to follow a prioritization pattern called the minimal marketable feature-set.This pattern, com- monly abbreviated to MMF, is based on the premise that not all of the wanted features on your list are initially required by your customer-base. In order to deliver utility value faster to your customers, decidewhich features are theminimal required feature-set, and build and release those first.Then put your product in front of the users and listen to their feedback.You may discover new insights and unanticipated feature requests that would add more value to the product than what you had already planned. During the project A good practice during the project is to in- sist on regular demos of the software being developed. A one-hour meeting every two weeks is a good pattern.Understand that continued on page 64