ERP Project Manager Diary: Talent Puddles and Turnips

Day 32 - Dear Diary, there’s only a couple more weeks in blueprinting, and then we can start building the ERP system. After all this time in meetings and arguments, it will be good to actually do something real. (Note to self: I may be too deeply immersed in this if I am referring to software as “real”).

I had a talk with the manufacturing team lead today, and while it was a good conversation, I am not sure that we solved any problems. He readily agreed that he was not comfortable with the process nor the direction of blueprint, nor did he really understand what was going to happen after blueprint was complete. Everybody talks too fast, they don’t explain things well, and they make him feel stupid if he asks any questions. Obviously, this is a problem. A guy with the self confidence of a turnip cannot effectively lead a design effort for the single largest end-user group. By the same token, replacing him is not going to be easy. The talent pool in this area is pretty shallow. In fact, it may not be a pool at all, it may be more like a talent puddle. I don’t know what I am going to do.

A Surprising Development

In a surprising development, I crashed the test ERP system today. I had some (rare) free time this afternoon, and used it to experiment in the test client. I was trying to see if the system allowed us to call the same thing different names, and somehow managed to cross-reference two materials to each other. When I subsequently entered an order for one of them, it apparently created an infinite loop of cross-referencing. I knew the response time was unusually long, but I didn’t expect the call from our basis team. “Dude. You broke the system. Nobody’s crashed the system. What did you do?” I explained things and everything got restored. My being able to do what I did was a simple configuration setting, it would have been discovered over time, anyway. Still, I need to login tomorrow, as there was mumbling about changing my security access so that I couldn’t actually screw up anything.

I thought about that though, and really, its people like me who put computer programs to real test. I mean, of course a computer program will work the way it was designed; isn’t that the purpose for a design? But how will it work when someone with a new problem is desperate for a solution? That person is like a hungry wolf eyeing a sirloin roast; he is going to take a straight line shot to the first solution he can find. Trying to make the ERP system do things it was never designed for – now that’s a robust test. Yeah, I need to keep experimenting.

Otherwise, things are going well!