Does a project manager have a responsibility to experience (hands-on) an information system s/he manages? What about the members of the governance bodies weighing in on decisions about scope, design, etc.? Does their judgment suffer from lacking an empirical perspective?
Last week I asked a colleague for his thoughts on effective project management. Although he offered a host of personal insights gleaned from twenty years in business analysis and information systems projects, I latched onto one nugget: “they should at least have a login to the system!”
The comment struck a chord. Early in my career, I decided that to be an effective manager of ERP strategy and execution I needed first to walk a day in the developer’s shoes. I paid my dues, in frigid machine rooms, code-development caves, UAT sessions, and conference room pilots. The benefits of those days in the trenches serve me well.
Many project managers believe that their talent is to apply a set of tools and best practices to any project; for them, the what, the why, and the for-whom are irrelevant to the job of arranging tasks, completing core deliverables, and delivering projects on-time and on-budget.
Clearly, this colleague disagrees. In his mind, a project manager’s ability to parse complex issues of scope and change management depends on a certain willingness to know the system, its inherent complexities, the business problems it intends to solve, and its efficacy at doing so. For him, a lack of interest in getting one’s hands dirty is symptomatic of an overarching detachment that ultimately renders the project manager ineffectual. In some ways, this colleague might say such detachment prevents other members of the team from viewing the project manager as a member of the team—which in turn could have broad implications on engagement and dedication, openness and honesty, and the overall success of the initiative.
What do you think?