It’s rare that we speak about getting the right resources for a project. Even more seldom is that we discuss how LIMS project behavior affects projects. Even beyond that, both personal and organizational behavior affect our LIMS projects.
Some Background
At this point in my career, it’s hopefully obvious that I’ve been on quite a number of projects. Some are more successful than others. We should probably be honest and refer to some of them as failures but we have a tendency to tell “happy path” stories about how these weren’t “failures” but “learning opportunities.”
But what might not be obvious is that I’ve spent a great deal of time studying both organizational behavior and personal behavior, both academically and as a matter of ongoing study. Most of the ongoing study involved all these projects I’ve worked on, over the years.
A Difficult Project Versus An Obvious Failure
I don’t believe in avoiding difficult projects. After all, if it wasn’t hard, they probably wouldn’t need me, to begin with. However, I don’t believe in getting involved with a project that I don’t think can be successful. I honestly believe that consulting should be about adding value to what the customer needs done. If I can’t truly bring something useful to what the customer is doing, then I don’t believe I should get involved with their work. I believe that’s just wasting the customer’s money.
When I speak with people who have little chance of success, even then, I don’t automatically hang up on them. In some cases, the person I’m speaking with doesn’t have the information they need in order to know the issues they have to resolve. If they want to know, that’s different than if they don’t want to know.
For those people who insist they’re on the right path, despite terrible issues on their projects, it’s not easy to pull off those blinders. If that’s not possible then I can’t do anything useful for them.
Two fairly recent conversations made me want to talk more about this.
Background Example # 1 for LIMS Project Behavior
First of all, something came up that reminded me of this particular situation I once got a call about. Here, I’ve disguised it a bit, as well.
It was a project that was merely dribbling along. It was not making much progress. It had significant, ongoing,, unaddressed failures. Backed by a whopping and increasing huge hunk of money and a significant passage of time, some portion was live but barely working. Other large, necessary features probably would never make it into this system. It would likely remain bare bones and barely working.
For starters, there was no-one to keep track of issues and get them fixed in an orderly manner. They had the wrong collection of people working on the project. Some project members not only couldn’t contribute anything positive but were actually causing some parts of the project to regress. In fact, the entire project continued to degrade to the point where they got to the the name-calling stage. No-one seemed to see this as a bad sign.
Organizationally, there was no real cohesion nor plan. There was no-one to manage and pull everything together. There was no vision nor manner in which to carry it out. No-one was tasked to see the big picture. Nobody had the financial acumen to notice that the petty cost-cutting the project had manically begun was merely a tiny drop in the bucket compared to the inordinate amount of money the project continued to bleed due to bad planning.
This project suffered both from issues at the organizational level and at the individual level.
Background Example # 2 for LIMS Project Behavior
On an entirely different train of thought, I ran into someone writing an article about what makes scientists collaborate.
As a part of this, one significant factor I included in all this is the individual scientists involved. Some are trained to be more collaborative, others not so much. However, some of these people are more flexible than others in their habits and views and can be Incorporated into a structure different from what they’ve previously worked in.
Another significant factor is that the organizations they belong to have their own views on this. Some organizations want people to collaborate and will work toward encouraging this. Other organizations DO NOT want collaboration. If you work in a place that doesn’t want people cross-pollinating then you’ll probably be punished if you try too hard to do that and, eventually, you’ll give up.
For example, in my last blog post, I mentioned visiting a research center that wants its people to collaborate. Its organization values this and promotes it. It brings in people who share that value. It’s currently successful with getting its people to collaborate.
LIMS Project Behavior
One issue I wrote about in the past is that project teams with the wrong collection of people are much more likely to fail. Organizations have a manner of working (i.e., a type of collective “personality”) and they should bring project team members in that fit with their manner of working.
When customers hire employees, they usually work to find people who are a good fit. When customers bring in other people to work on their projects from various external services groups, they don’t tend to do this.
Some customers have enough clout that they can obtain appropriate resources. They do get some amount of choice. Many customers just don’t have that kind of clout. As such, some will be lucky and get resources that get their projects done in-time and on-budget. Others won’t be that lucky. All of us should note that projects shouldn’t depend this much on “luck” but it is what it is.
The Organization and Project Success
In all of this, you have to start with an organization that has the ability to understand these types of projects. The organization has to have a structure where it can understand the issues and make appropriate decisions about them.
In consulting, we often brag about how we “made” projects successful. If they’re not, we point-out that the customer was “difficult.”
While a consulting company can be a bunch of yahoos that will do a terrible job with customer work, they can also be quite skilled and do appropriate work. However, even with the best resources, they can’t really “make” a project successful or unsuccessful.
Consulting companies that are working on a LIMS project aren’t necessarily there to affect the levels of people above the project. Regardless what anyone says about this, those management layers above are typically set and not going to budge based on what the LIMS project is doing.
LIMS Project Behavior and Communications
Some upper managers still see LIMS, ELN and LES projects as fairly small and probably simple to accomplish. It’s difficult to get the message to some of them that these projects can easily go into failure mode. Often, by the time they’re aware of this, the project is so far off the rails that it might not be recoverable. At the least, it might look unrecoverable.
My Two Top Tips to Upper Management
If there’s a single upper manager reading this, I want to give you and your project team my two top tips to help you avoid this kind of failure:
- Communications. Communications have to be ongoing and appropriate. Never assume anything. There’s a multitude of books, courses and consultants out there to help you with this if you have any doubt how to make it happen.
- Adjust accordingly. Little should be set in-stone. If it doesn’t work, consider why it doesn’t work. Maybe it will never work and needs to be entirely changed. That could apply to a process, a piece of software, or a person.
While the likelihood that your upper manager will read this might vary, organizations run from the top down. People on the bottom can work hard but there’s a limit to what they can do if good habits aren’t promoted and enforced starting at the top of the organization.
Good Work Habits Aren’t Enough
In the last section, I did basically say that good work habits aren’t enough. So, while I used to think that I could work on a project and use my knowledge to promote better habits among the other project team members, consultants or employees, I now know that’s not always true.
When a project has truly derailed and there’s no consideration toward evaluating and fixing anything on it, there’s not much to be done for it by the individuals.