A couple days ago, I wrote about “shifting the blame” – the tendency projects seem to have of fostering the need for its team members to spend their time looking for others to push blame and problems onto. In writing that post, I got into my project manager mode – I was thinking about how if we’d just create sensible project plan, stick to it, work together, etc…, how well it would all go – how much progress we could make.
Considering how poorly projects in our industry and in all software industries perform even with all the great new tools and ideas people espouse as solutions, one might think we’d wise-up and look for the root cause of our problems.
However, as I started to think backwards across all the projects I’ve worked on over the past years, I’ve seen plenty of politics-over-efficiency, people jockeying for position, fear (lots of fear: of being blamed, being demoted, being laid-off, etc…) and how it has greatly hindered the projects.
When you get a large project with many companies servicing it, the software vendor, several services vendors, employees – you get a mix of people that are not necessarily motivated to work together. After all, why help another person get credit for the good work that you probably put so much effort into? That’s often a primary issue. And with the competition so fierce among the software vendors, there is a need to make sure they look good to the customer. And the services groups can’t let the software vendor look too good or they look bad. This seems to be an endless job of repositioning to stay on top.
It’s naïve to just expect everyone to work together as a team. I’ve worked with projects where some manager will announce that that’s what will happen…and then does absolutely nothing to actually make that happen so, it doesn’t (and then they wonder why).
Keeping projects and teams on track is hard work. It doesn’t just happen. Shove a bunch of people together to work on a project and those rare stories you hear about how they just come together and make it all happen are truly that rare. If you depend on that, it’s like sitting at a roulette table planning for a specific number to pop-up. But laboratory informatics projects are too expensive for that kind of gambling, whether it’s a LIMS, and ELN, a HIMS, etc…