Don’t Gamble with IT

During the height of the dot-com boom in the late 1990s, legendary investor Warren Buffet was roundly criticized for his rejection of Internet company stocks. He famously responded to his shareholders: "You are neither right nor wrong because the crowd disagrees with you. You are right because your data and reasoning are right." Of course, in time, Buffet's data and reasoning regarding Internet companies was proven correct, and the dot-com "boom" is now known as the dot-com bubble. The lesson for IT managers? You can minimize the risks inherent to selecting IT projects by gathering the right data and applying the right reasoning.

George Heilmeyer, a former director of the Defense Advanced Research Projects Agency (DARPA), which funded the development of technologies that provided the Internet's foundation, laid out a set of questions, known as Heilmeyer's Catechism, for assessing the project proposals DARPA was asked to fund. As an IT manager, you can use Heilmeyer's reasoning to gather the data you need to make sound decisions about the viability and impact of projects that you're asked to take on. You can use the same questions to ensure that you're providing the right data to management in your project plans. Heilmeyer's Catechism, which I've paraphrased here, is actually eight sets of questions. Your answers to these questions will put you on the road to a solid project proposal.

1. What Problem Are You Trying to Solve?
In IT, technology doesn't exist for technology's sake; rather, IT exists to enable or enhance a business activity. Historically, IT specialists have been guilty of adopting or recommending technology either because it's interesting ("the cool factor") or because it's new ("the bleeding edge"). The result is a solution in need of a problem. Not only is this behavior costly, but it also alienates end users, who just want to complete the tasks that have been assigned to them. Asking a project's planners to clearly define the problem they are trying to solve will ensure that a genuine problem exists and that recommended changes aren't merely a pet IT project.

Another reason to ask this question is to set scope. If the primary problem is ambiguous, the project will inevitably expand to solve many problems that might or might not address the original concern. If project planners can't clearly define the problem they want to solve, they need to be sent back to the drawing board.

2. How Is the Problem Being Addressed Right Now? What Are the Limitations of the Current Solutions?
Once a problem has been clearly defined, the next step is to ask how the problem is being addressed today. Although it's possible that the problem isn't being addressed, more than likely, some sort of solution or workaround is already in place. If a project's planners can't articulate their organization's current approach to a problem or develop convincing proof that the problem isn't being addressed, then you can safely conclude that they haven't conducted enough research.

The second question in this area asks whether and how current approaches to the problem are limited. The answer helps define whether the current approach is inherently insufficient or just poorly executed. If the latter, you must decide whether your organization wouldn't be better served by improving execution of the current solution than by funding and implementing another solution.

3. What's New About Your Idea?
Answering this question is crucial for the success of any IT project that involves customer software development. In comparison to current solutions that your organization has implemented and those that exist in the marketplace, what is new and unique about your proposed solution? Inability to answer this question indicates either that there's nothing new about the proposed solution and it's likely that the same solution already exists, or that the project hasn't been properly researched. You shouldn't reject projects out of hand because they don't implement a new or novel solution. For example, a proposed solution could promise to perform the same basic functions as an existing solution, but at a much lower cost.

4. What's the Impact if the Project Is Successful?
If a project's planners make it through the first three sets of questions, then the proposed project likely has merit. This question is designed to determine and quantify the project's expected outcomes. As someone proposing a project, this is your opportunity for the hard sell—painting a picture for management about how the business will look when your project succeeds. For an IT manager, the answer to this question will be a key part of calculating the project's ROI.

Keep in mind that in addition to its positive effects, a successful project can cause or highlight problems in other parts of the business. This potential impact must be articulated so that you can compensate for or otherwise address it in the project plan. For example, you could develop a world-class business-to-business (B2B) e-commerce portal, but your company might lack the supply-chain management to fulfill orders cost-effectively.

5. How Will Short, Intermediate, and Long-term Results Be Generated?
This question asks how the project will be organized and managed to deliver short and intermediate results and long-term sustainability. In the short term, the project team is assembled and managed. In the intermediate term, the project is transferred to a team to maintain it. Over the long term, the project must fit into an organization's overall business and technology strategy. If your IT staff is inexperienced, they will likely need your guidance in answering this question.

6. How Will You Measure Progress Toward Success? How Will You Measure the Project's Effects?
The larger a project is, the more important it is to have milestones to meet and use as checkpoints. Milestones will reduce the complexity of the overall project into more easily manageable and attainable goals. Measuring progress toward milestone completion will help you, as an IT manager, intervene early if the project should fall out of scope or schedule.

The answer to the second question is what executive management will really pay attention to—it's the bottom line. Organizations measure what they value and value what they measure. Designing the project measurements before the project begins will help the project team build or develop the appropriate instrumentation or evaluation methods so that the project's impact can easily be measured at completion. This information will be necessary in calculating the project's total cost of ownership (TCO) and ROI.

7. How Will You Know When You Are Finished?
This question is often overlooked, but the answer to it is essential for any project for which no absolute criterion to build to exists (as is frequently the case in software development). In addition to establishing milestones, ask what the exit criteria for the project will be. Failure to define exit criteria can result in a project that continues to cycle even though few marginal gains are made. Initial software releases don't have to be perfect—this is what subsequent releases are for—but they do need to accomplish their expected outcomes. Exit criteria will define the point at which the project is finished.

8. What Will It Cost?
This question saves the best for last: How much will the project cost? This information isn't necessary only to calculate the project's TCO and ROI. Because IT resources are relatively constrained, resourcing one project can necessitate postponing or canceling another project, and you will need to assess opportunity costs and select the project that makes the best use of funds, staff, and other resources. When evaluating the projected cost of a project, always keep in mind the Pentagon's law of big projects, which states, "Anything big will cost more and take longer then you initially think." Years ago, a project manager whom I worked with told me that she took any cost/time estimate she received from a technologist and multiplied it by pi (p). Although it was unscientific, her method created more accurate projections.

Take No Bets
As an IT manager, when you evaluate a project, you are in effect being asked to place a bet, much like investors such as Warren Buffet, on where you think the greatest possibility for success exists. Leave the gambling for Las Vegas and use sound reasoning and solid data to make your decisions. Employing Heilmeyer's Catechism will take you a long way toward backing a winner.

End of Article