Imagine a scientist who has worked through some heavy-duty calculations, on her way toward a solution to a problem. What good would her effort be if part of her answer was, "A miracle happens here"?
In your project evaluations, you' l l run into situations where you' re being told that a facet of the project can happen by virtue of some capability of the software or hardware you ' re considering. Dor example, you' l l see a problem on the horizon and query the software vendor, "I don' t see any place where we can accomplish this. Does the software really do this?" To which the salesperson (not the software engineer) will reply, "Oh yeah, we can do that!"
The salesperson doesn 't tell you how you can do that—he just stipulates that the software sure can do that. Your own development staff might be convinced that they can do that—whatever "that" is. You may have doubts, the customer might have doubts, and even the project sponsor might have doubts. Nevertheless, you let the project go forward because of the "a miracle happens here" phenomenon—you really believe that maybe the development staff can make "that" happen.
Later, you ' re disappointed to find that the software cannot actually do "that." Not, at least, without standing on your head and spinning around twelve times to get it to do that. When you phone the software engineer, you ' re surprised to find that she admits the software really can t do that, but the salesperson insisted on being the one to respond to you. In other words, you were lied to simply to make the software sale. The chances of the project being stalled—or, worse, cancelled—until you find someone who can do "that" increase dramatically.
Do you get the idea? If you sense that someone in the project group is talking about a miracle, then you need to call them on it and work out the issues. Projects aren't built on miracles but instead on cold, hard constraints of time, budget, and resources.
Was this article helpful?