Does this describe your company? Well, doesn't it describe them all?
Time and again inefficiencies in resource allocation and project management damn project teams to a hard slog if not to outright failure. I want to be clear in stating that I'm no project management expert, but regardless of expertise I never discount the commentary of any astute observer.
What I find to be the most effective means of breaking a project team is attitude and pride. I don't think the computer software trade is unique in its dependency upon the dedication of its individuals for success. Actually, I'm certain it's not. A sense of conviction and oneness with the overall direction of the company is an imperative and oft-overlooked prerequisite in assembling any project team. Without that 'spirit' [and I'm not suggesting I know how to universally achieve it] the group is far more vulnerable to things like personal attitude and bull-headed pride. How many times have you been on a team where one or more members deviated from the greater objective through a sense of unique pride, and in doing so, derailed the delicate balance-train any project teeters upon?
Attitude and bull-headedness can also affect an otherwise talented project manager's ability to do proper resource allocation. Are team members tapped to advise on the decisions they're best qualified to ruminate on? Or are members selected based mostly on personal relationships or convenience? Sometimes in companies, cliques can form which are reminiscent of what you might find in your local prep academy. Not to lean toward conspiracy speculation, but if you see one low-performing project after another staffed with the same folks, something just might be amiss.
Always be sure to look throughout your company [with an eye to schedule/availability of course] to be sure you have the best instructional talent, writer, developer[s], manager, and a good technology adviser. The best teams are assembled objectively with a primary eye to the best interest of the client. Overlooking preconceived notions and rash assumptions [and not ignoring the blatant] will go a long way to building a spirit of trust and unity. Experts exist for a reason, use them so your team members know they have the support they need. Does it seem like I'm speaking the obvious? Look at your company, and if you do postmordem analysis on low-performing projects, look for the hallmarks of loose technical architecture planning and/or arbitrary job assignments. Maybe you're in the minority and you don't have any low-performing projects, but if that were the case you probably wouldn't be reading this far!
I hope this gives you a bit of pause and fosters some discussion on the topic of project team building without cynicism or preconception. Of course, some projects are damned to fail from the start due to political goofiness built into a lot of giant corporations, computer environment flaws, communication disconnects, etc. Those are fixed risks, though, and validate even more a need for a healthy internal culture and the kind of good project management that only comes from talent and experience. The kind that cannot come from any 'certification'.
P.S. Sorry about the balance train, it was a silly analogy from a railroad nerd :)
Post new comment