The Sorry State of Project Managers and Business Analysts

Has anyone noticed how trivialized two supposedly critical functions in the IT world have become? I’m talking about project managers and business analysts. I always thought of those two functions as pivotal, as make-or-break activities on any development project. (Forgive me, I thought of them as maybe even more important than the programmers.)

Most PMs seem to be doing little more than project bookkeeping and updating preposterous, often ponderous and usually incomprehensible documents politely referred to as project plans and progress reports. And BAs have become people who are little more than note-takers at rambling meetings (think of every Dilbert comic strip you’ve ever seen) who attempt to use their notes to create requirements using a barely understood technique called UML (unified modeling language) that creates long, wordy documents too technical for business people to understand and not technical enough for programmers to work from.

[ I do lively presentations on this and related topics - mhugos@yahoo.com ]

I always thought of the project manager as the pilot who steers the project toward success as it moves along and unexpected things happen. And I thought of the business analyst as the navigator who defines the business requirements for the system and who keeps track of those requirements and speaks out for business users to make sure they get what they need. Yet in practice, over the last decade or so, in spite of all the lip service to the contrary (and all the certifications notwithstanding), both roles have mostly turned into powerless low level staff positions. Look at an org chart and see where these people get put in the general scheme of things on a project. If either of them were to actually speak out or take a hard stand on an issue, they’re likely to get fired.

Question: If PMs aren’t piloting and BAs aren’t navigating (and if they don’t have the authority to do so anyway) then why are we surprised at the incredibly low rates of success on IT projects? Who is piloting and navigating? Is anybody doing those things, or are they being done by steering groups and IT governance committees too far removed from the action and too slow to make decisions to be very effective? And so then, if we want to improve project success rates, should we: a) continue adhering to the “best practices” that led to this current state of affairs; or b) try something else, and if so, what else? What skills, powers and authority would PMs and BAs need to really do their jobs?

[Michael Hugos, principal at Center for Systems Innovation [c4si], elegant solutions to complex problems; mentoring teams in agile systems development. His newest book is Business in the Cloud: What Every Business Needs to Know about Cloud Computing.]