Earlier this year, I spoke with a leading data science manager at Teradata, and asked him what the secret of his success was when it came to making IT projects work. His succinct answer was: knowing when to pull the plug.

In his case, the projects underway were big data projects. He was in charge of R&D, so it was often impossible to predict project outcomes. Nevertheless, after awhile you had a pretty good sense as to whether a project was heading in the right direction, and if it would ultimately deliver what you were hoping.

I had a similar experience as a project manager when I was asked to take over a project that was one year and one million dollars over budget. Much of the software had been written without firm requirements definitions and user agreements. Although the software had never been in production, a good portion of it was already in maintenance mode, with developers frantically trying to incorporate late arriving user enhancements that should have been captured during requirements definition.

The project was never going to be finished unless someone put a stop to it, so I sat down with stakeholders and proposed doing a project reset so we could see what was good to keep, and what we had to do to get back on course. I remember leaving the meeting thinking that I could get fired, but after the dust settled, everyone agreed with the idea — even if the project would take longer.

How can you determine why projects fail?

Emmet B. Keeffe III, cofounder of iRise, which works with 500 of the Fortune 1000 companies on software visualization, agrees that there is a time in projects when it makes sense to press the “panic button” and to stop work to assess where a project is going. According to Keeffe, software visualization can make projects “look and act so real, they’re almost indistinguishable from the real thing.” He references recent information that indicates that 45% of enterprise software development projects miss their mark, which from a management perspective is a daunting amount of wasted effort.

“To know why projects fail, we need to look at the entire software development process,” said Keeffe. “Often, what we find when we visit companies is that the upfront requirements definition for software projects is usually written by IT. In these cases, IT meets with the end business users, but it is ultimately IT that does all of the requirements documentation, and this is often ‘the beginning of the end,’ because the end users can’t understand the requirements that IT writes.”

When it is time for end business users to perform an “acceptance test” on the final software product, they often come back to IT and say, “This isn’t at all what we expected!” By this time, so much anticipation and expectation has been built up that it could cost a project manager his job.

How do you avoid this pitfall?

Using simulation and prototyping tools that enable you to meet often with end business users throughout the development project helps. “In these exercises, IT can show end users a model of how the software will work and then ask, ‘Is that what you meant?'” said Keefe. In this way, end business users, and not just IT, are directly engaged in the project.

Does this eliminate the need to pull the plug?

Even with prototyping and simulations, there will still be times when a manager has to make the “pull the plug” call. There might be a sudden, unexpected change in the business or some other factor arises that no one could anticipate. But if you have to make that decision, at least everyone will understand the reason why, and know that it was the right thing to do.