Tuesday, June 22, 2010

Be Careful What You Ask For

Software projects are inherently risky, and the ways to run astray begin even before the project begins. The quality of a procurement solicitation governs the results of a project, laying a solid foundation for success or creating unnecessary problems that doom a project.

Since the negative examples are often more illustrative, here are a few pitfalls to avoid:

1. There is no such thing as etcetera in a specification. Over the past few weeks I have reviewed requests for proposals that list open-ended requirements for integration, mentioning one or two specifics and then the dreaded "etc." rears its head. The result is that vendors either decide not to bid or pad the price to cover the risk of the unnamed integration.

2. Fixed price requires fixed specifications. If you choose a fixed price contract, vendors cannot determine a price without complete and detailed specifications. Fixed price combined with vagueness can result in a game of change orders where bidders price the minimum and then add dramatically to the cost and time through a series of change orders. Some integrators specialize in this approach because it is difficult to switch vendors in the middle of a project.

3. Watch out for gold plating. If you need a system for ten people, don't specify that it must scale to 10,000 users. Otherwise, you will end up with a city bus when you had a compact car in mind. Vendors will do their share to upsell and goldplate all on their own without encouragement from the solicitation.

4. Don't dictate how to get there. Encourage vendors to use creative approaches to solve your business problem. You can easily ask for more than you need and therefore pay more than you needed to pay for a solution.

5. Don't wait too long for results. Be sure to break the project into short phases with measurable results. There are many software projects that drag on for years before shipping a product, only to find out too late that it does not meet business requirements.

Writing a solicitation that is specific and detailed, without reaching for the moon and the stars, can be the start of a successful software project.

Friday, June 18, 2010

Why Information Technology is Like Exercise

I must confess that I don't like to exercise, especially when it's purely for health reasons. I haven't run far and long enough to become addicted to the runner's high. I feel better after I run for the rest of the day, but it still takes effort to get up early and get out there. For me, exercise is best in retrospect.

On the other hand, I am a huge gearhead. I like researching the latest camping equipment, golf clubs, fishing lures, backpacks and even running shoes and socks. It feels great to gear up to be ready for fitness. Sports Authority can testify to my optimism for fitness.

At the end of the day, though, the gear doesn't make you fit. You have to get out there and run, bike, swim, hike, or hit that ball or puck to stay in shape.

Information technology is similar, in that it takes more than gear and software to improve business processes. The most important ingredient is the will to change and openness to assess the way an organization works and find better processes, then automate them if necessary. Buying the latest and greatest technology does little for an organization not willing to invest the time to use the new tool.

When the will to change is absent, no amount of money, hardware or software can make up for it. The examples of failed software projects are legion, and many can be traced back to a lack of leadership or a failure to make tough decisions and tradeoffs. In other cases, the failure is in the last mile of the project: failing to train users and encourage adoption of the new system.

Over the years, we have had the good fortune to work with a large number of IT leaders who were not afraid to shake things up, take chances, and make tough decisions in order to reach their goals. We usually know at the beginning of a project whether the client has this requisite toughness, and its presence is a reliable predictor of project success.