“You want to do what?? Really?“
Project managers are skilled in coordinating resources to deliver a specific product or process. Usually we’re provided the basics of a business case and often, a subject matter expert (SME) to fill in the technical details.
But what happens when the goals or the project approach don’t make sense to you?
Especially early in a project’s life cycle, project managers are often bulldozed by their SMEs and Sponsors into just focusing on getting the project on-the-road.
When will all that planning and organizing be done? When can we start coding?
Sound familiar? Unfortunately questions of this type are far too common. Project SMEs and stakeholders may understand the need for requirements gathering, but few have patience with a project manager who questions the framework of an initiating business case or a solution approach. After all, the project manager is not necessarily a subject matter expert and may not know much about the business operations.
That lack of business/technical knowledge, however, should be a reason to question authority! A project manager, uncomfortable with an approach or business justification, should challenge the team members to explain their positions.
While PMI processes don’t specifically call for a validation checkpoint when a project manager is assigned to a project, it is good practice to add one. Don’t wait until the cows have left the barn … ask the stupid questions of your team at the start!
It’s much easier to claim ignorance during the Initiation or Planning phases than it is during Execution. Those “clarifying questions” really don’t fall into the “stupid” category, unless they aren’t asked.
I was recently asked about managing an infrastructure conversion project. While I was familiar with the technology basics, I thought that a “refresh” was warranted. I wanted to see what solution approaches a project team might be considering. I probably shouldn’t have been surprised, but the “industry experts” posting on the subject, were offering the same basic structures that we had applied 15 years ago!
Document the environments, research the existing-state performance / stability issues, understand the business and application constraints. Perform these tasks as the foundation to planning. That wasn’t anything new!
Then it hit me. The SMEs reading that advice probably had less than 10 years of experience. They wouldn’t have been working 15 years ago, at least not in senior/planning roles. They probably knew the functions and the features of the technology products that they were about to implement, but they might not have the process perspective of an experienced project manager.
Less concerned about the technology specifics, I shifted my prep focus to the broader topics of the project approach. Let the subject matter experts do what they do best … provide specific information and expertise … but don’t assume that everything is OK. Ask questions about the business environments, the background work and the assumptions. When something sounds obscure or ill-defined, it often is. Ask questions and look for answers.
The answers that the project resources provide might highlight an area that was overlooked or a linkage that wasn’t considered. Conversely, the answers may provide no additional insight to them, but they will certainly add to your understanding of the project.
Properly done, such review sessions may allow your new team to show the depth of their knowledge and what they have thought about. Challenging authority doesn’t have to be confrontational (and shouldn’t be). It should be an opportunity to walk through the project’s key components and allow your team to express their knowledge. Where additional information is required, the assigned resource can later return to the team, after completing their research, and be the “answer man” (or “answer woman”).
Not Everyone is an Expert
You might find that you weren’t the only team member who didn’t understand a particular term or topic. On past projects, I’ve added regular technology and business reviews for the team members to give them opportunities to learn about their own environments.
These reviews were hugely successful in bringing the various team members up-to-speed on the project’s business and technology components. While watching 20-minute presentations doesn’t turn anyone into an “expert”, the briefings do give the team members (and stakeholders) a common understanding of project terminology and a better perspective on the issues that each face.
Questioning “the authorities” and challenging them to explain what they are recommending and why, can be an important part of project initiation. But remember, how those questions are stated, can be equally important. Be respectful. Be honest. Be focused on the project.
- “The Subject Matter Expert” by Brad Egeland, March 2012 http://pmtips.net/subject-matter-expert/
the project manager who fails to seek out and include the right subject matter experts is likely to deliver an end solution that isn’t 100% dead-on. The result will be a customer who is less than satisfied and a solution that may not deliver the expected or desired results.
- “Can a Project Manager not be a Subject Matter Expert?” by Meade, Dec 2007 http://itprojectguide.blogspot.com/2007/12/can-project-manager-not-be-subject.html
PM_Value = (Reduction_of_Project_Risk *100) + Increased_Project_Effectiveness + Increased_Project_Efficiencies