Accountability is an absolutely crucial element in business. It's what keeps projects on schedule, or prevents good money being thrown after bad. It's usually fairly easy to figure out who is accountable, and for what, but I've always been surprised at the reluctance some people seem to have to actually either accept accountability, or to enforce it.
The best example of a failure of accountability had to be from my experience at CharlieNet. Like so many dot-coms, the code written as a "prototype" was rushed into production, where it wasn't really capable of keeping up; much of time the engineering staff spent working on the site was to simply keep it running, attempting to optimize bits to allow for further growth, and so on.
Rarely do I find companies willing to actually put in some time and effort to rework their software from the ground up, in order to extend their capabilities. I give the CTO high praise for recognizing the need. The plan was to switch from the language we were using, Perl, to another language, Java. Now, this was back in '98, before Java became the industry standard (and plague) it is today. The CTO asked a contract manager, who worked remote with two engineers "of his own", to investigate the possibility of reinventing the website in the new language.
Apparently, three months before the presentation I was witness to, the CTO had asked for a simply report on the viability, to be returned in a month. Instead, the remote manager (let's call him "Jim") put his two engineers to work on actually churning out a proof-of-concept prototype, and it was this prototype that was demoed to us two months after the original report was supposed to be returned.
The prototype was fairly impressive, but much of it was based on the same prototypical design our current codebase already had, simply transcribed into a different language. The CTO asked my opinion on the project, and I said I thought the technology was proven, but we would need to basically start over from design; one of the reasons we were having issues with our existing software was due to a poor design model, and that problem was unaddressed in the demo presented.
I had some work on the existing site to be done, and I was still trying to pick up Java, so the decision was that the remote team, under Jim, would work on the new design for a month, while I wrapped up what I was doing and got up to speed on the new language. During this month, though, I continually queried Jim and his team to see what progress they were making on a new design model. Consistently, the answer I got back from Jim was a question, "How's your Java?" This was a meaningless question, because any real software engineer can tell you, software design isn't dependent on language; it should make no difference if I knew the language being employed or not, to be able to understand and provide constructive feedback on a design.
This went back-and-forth for the whole month. I'd explain that I didn't need to know Java to know a good design, and would get no response. I'd query for the model again and get back the question "How's your Java?" The day I was supposed to start working on the project fulltime, I finally got the truth from Jim: The object model used for the prototype was the object model they were moving forward with.
I went ballistic. I gave him a good piece of my mind, and determined at that point that not only would I not work on the project, I would not work with him. I went back to working on the existing site, and let Jim and his two engineers continue working on their own. I followed with morbid curiosity their progress during engineering meetings. The last straw dropped at the beginning of September; Jim continued to present to the CTO and the team that they'd be done by the end of October. Then it was the end of November. Then it was mid-December. Nobody else was transitioning to the project; I got a sense that Jim didn't want anyone else to interfere with his little project.
His project was cancelled in November, when he attempted to push back delivery another month, for the third time. This was the first sense of accountability present in this project, and it had to come down from the CTO. After recognizing the issues I had with Jim (and agreeing with me), the CTO was forced to shut the project down, because Jim could not hold himself, or his team, accountable for the expectations that were set.
It's just extremely unfortunate that several months later, after the entire management team had left or been fired (within a span of three months, the CEO was removed, the CFO, who took over his position, quit, and the CTO resigned). Jim was eventually offered the CTO role, and his relocation (since he could not be an effective CTO remotely) was paid for. I had hopes, because he gave our engineering manager the go-ahead to revive the "redesign" project, but then they were dashed because apparently, after three weeks of constructive work on the project, Jim clarified that what was greenlighted was to simply continue working on the project he'd initiated six months before, building off the code that had already resulted in three months of delays, and which was obviously not worth working with.
What's worse, Jim decided to quit the company only a few weeks after being relocated by the company, taking a job at the company next door. I don't know for sure, but I'm betting he was never required to repay the relocation costs. The company was folded back into its parent company less than a year later.