As I familiarize myself more and more with the MIKE2.0 framework, it’s obvious to me that it’s highly contingent upon collaboration. In general, collaboration can be a very good thing. Sometimes, however, something is lost among all of the buzz about collaboration, Web 2.0, and Enterprise 2.0. In particular, I’m talking about the increased difficulty involved on “community” projects.
In a series of posts, I’ll make the case against collaboration. For today, I’ll address some of the benefits of minimizing the number participants on information management projects.
Disclaimers
Now, don’t get me wrong here. I’m a big believer that the whole can well exceed the sum of its parts. Further, many–if not most–large IT endeavors cannot be handled by one person, no matter how talented. Let’s not forget that many organizations may not employ an individual capable of being the single point of contact. Finally, even “one” were possible, it’s typically not desirable. A defection of employee exit can cripple a project of this ilk.
With these caveats out of the way, let’s talk why collaboration might not make sense for your particular IT or information management (IM) project.
Understanding
In my post a few weeks ago, I wrote about how my current project entails an application fraught with superfluous complexity. While the details aren’t terribly important, suffice it to say that my client’s current app is about a two on a scale of one to ten. Its replacement is about an eight.
Mitigating this complexity, however, is the fact that I am primarily dealing with one person at my new client. Let’s call her Kayla. She’s a smart and seasoned professional who knows the following:
- the old application
- her organization’s policies
- the data
- the culture and the key players
Long story short: Since Kayla is stepping up to the plate, I can spend most of my time ensuring that she gets it. In turn, she’ll work with end users after I depart. While I am working with others at her company, she’s made it clear that everything should go through her. She’s not being territorial; she just knows how everyone and everything works there. Like me, she wants the project to be successful and making sure that she’s the “super user” is the best way to accomplish that goal.
Communication, Responsiveness, and Clarity
One of the biggest issues continually haunting IT projects has nothing to do with information or technology. That’s right. Communication issues are the bane of many data and system migrations and have been for quite some time. Long, essentially pointless email chains often confuse, rather than convey. We’ve all been there. Everyone’s copied because of fear of excluding someone from the loop. Or maybe it’s death by meeting. Regardless of the medium, we’re left wondering what on earth we’re trying to do.
Fortunately, I don’t have to deal with these headaches on my current gig. I know that I can send an email to Kayla or call her up to get an answer to a policy, data, or system question. No large email chains or meetings required.
Accountability
Now, I tend to approach the notion of accountability from the vantage point of a consultant. I love the increased accountability of dealing with a single person. Stop me if this sounds familiar: On past projects, I have had to junk or significantly rework documents, custom reports, mini applications, or system configuration because Person A made a decision that Person B was supposed to make. (Obviously, the “authority” issue is highly related to the previously mentioned communications one.)
Again, I really enjoy being held accountable by one person–and concurrently being able to hold her accountable. It’s one of the main reasons that my current project will, in all likelihood, come in ahead of schedule and under budget. I’ll be the last person to take credit for this. Yes, some of this is my doing, but I can only be as good, efficient, and effective as my clients let me. I can say without fear of accurate contradiction that I’d feel worse about the project if I had to ensure that everyone was at Kayla’s level. They don’t seem to have the same skill set and they sure haven’t participated in the project to the same extent that Kayla has.
Simon Says
It’s rarely a wise idea to staff projects with a single person. From a risk mitigation standpoint, I can think of few more foolish decisions than to concentrate all knowledge and power in the hands of one person, no matter how benevolent, loyal, or sharing. People win lotteries and quit jobs for all sorts of reasons, even in a bad economy.
At the same time, however, it’s important to consider the potential limitations and drawbacks of collaboration. Ask yourself if the potential drawbacks are worth its benefits.
Feedback
What do you think?