I’ve never been an A-Team fan. I may have seen just an episode or two, but it was enough to build an opinion that regardless of what episode was about, the A-Team has just one solution: board their steel-reinforced van, crush the entry gate to the bad guys’ HQ and swarm the them with the endless flood of sharp-pointed lead. Any hostages involved? Discretion advised? Innocent civilians around? Who cares? BANG, BANG, BANG, here we are, A-Team, ready to rumble!

http://youtu.be/_MVonyVSQoM

What’s the point in going back to 80s? That’s because I’ve found an interesting parallel between A-Team and some IT projects I’ve seen. I call it an "The A-Team syndrome". What’s it about? Let me quote some typical statements (exaggerated, for illustration purpose):

  • "Hey, we have the best people, we don’t have to care about plan, coordination or whatever!"

  • "We’re dynamic and agile, we ain’t gonna fetter our feet with procedures or bureaucracy!"

  • "Integration? If things are done properly, integration will go smoothly at the end."

  • "Why bother with setting responsibility or ownership - people should be proactive, they should identify the necessary work to do and do it!"

  • "Communication? What about communication? Don’t you people talk to each other?"

I do understand the agile approach and the trend of minimizing the formalities (there’s nothing worse than analysis paralysis), but even agile projects require some order:


  • Don’t reinvent the wheel each time - re-utilize the knowledge from past: checklists, blueprints, even plans (as references). There are some elements that are needed on 95% of projects - better be prepared, don’t you think?

  • If you have more than 1 team, some coordination is required -> the responsibility for an asset or general area has to be set or you’ll end up with some work done twice (or more) and some work not done at all. Coordination requires some bigger picture - at least basic understanding of what is done in the streams of work being coordinated.

  • I hate the word “stakeholders”, but even on agile project you can’t assume that all interested will take care of what they need (and monitor the work in progress) - it’s project’s task to identify the needs to fulfill (and do that), regardless of who’s the beneficiary.

  • Integrate since the beginning, you’ll save a lot of time (and money … and bad blood …).

  • Information doesn’t flow telepathically from mind to mind. If an important decision was made - all appropriate audience should be identified and communicated to (regardless of form - written or oral). Key decisions should be somehow cataloged, so it’s easy and fast to verify it there are no contradictions or inconsistency

Original A-Team succeeded every episode, but IT projects done “the A-Team way” won’t. Seriously.

P.S. All the resemblance to actual projects and people are accidental and not intended ^_^