Piloting Projects into the Ground

"Is it coincidence that the craziest fools have the strongest belief that they're right?"

Ben Kenney - "Wrong"

12-hour days mean a lack of patience, blogging time, baby time, guitar time, and any other time other than eating, sleeping and working time. Even eating time gets compromised, which makes me very cranky. At my last unofficial count, I'm up to doing the work of 11 people. It's no fun being the manager when there's no one available to delegate to.

So, until yesterday, my team was taking part in a pilot project to test the effectiveness of a new piece of software to be rolled out in the fall/winter. It doesn't work all that well, and we were losing patience with it, but we were trying to make it work. Yesterday afternoon, I was taken off the project for a number of reasons, one of them being that I was unable (unwilling?) to follow the precise instructions I was given for operating the software.

Now, as manager, am I not ultimately responsible for the workflow in my unit? We tried things the way the project team wanted them done, and it didn't work. And it wasn't for lack of trying. So I asked my team (because I let my subordinates make decisions, shocking, isn't it?) what they thought would work. And they had a few suggestions. And we tried them. And they didn't work. But they didn't not work as badly as the original idea...follow what I'm saying? There was enough promise with the new workflow that with some tweaking, we had a chance at making it work.

So I bring this up to the project team, thinking they'd be grateful to have a second option. Nope, they want us to go back to what has no hope of working. Meanwhile, this is costing us time and money and people are getting upset and frustrated, so I draw the line in the sand and say no, this is how it's going to be. My youthful stubbornness getting the better of me, they thought. But then I went over the rationale for my decision, and people agreed that it made sense. BUT THEY STILL WANTED ME TO DO IT THE OTHER WAY.

Long story short, my director caught wind of the situation and pulled the plug for compassionate reasons, knowing that I was already overworked and apt to blow a fuse and that the project was doomed to failure because of the overall shoddiness of the software anyway. I feel sorry for the sucker who gets suckered into this job next.

So basically, because of my boss' intervention, I'm off the project, I don't have to do everything they want, but I still get to keep the software in case we end up finding a way to use it. Which is what I wanted in the first place. ;)

On a larger-scale, here's the question: how do you go about running a pilot project to test new software? We had it introduced into our workflow without even bothering to find out whether it was even STABLE (it wasn't) or able to do what it advertized (yes, but only in very precise and unrealistic conditions). We were given one set of possible directives, and if those directives didn't work, we were just to keep doing them until further notice.

If it were me, I'd have assembled a working group of people who are more comfortable than the average with various software packages in order to do some troubleshooting, and giving them free reign to find out what works and what doesn't, while working with the project team to record the strengths and weaknesses of said software, which would then lead to joint recommendations on how to incorporate it into the general workflow, while giving instructions to everyone in the workflow chain on how to provide feedback, which would be used to further refine the procedures. And if anyone found a better way, they would be welcome to keep working that way. But that's just me.

Am I the only one who thinks that makes sense?