Have you ever completed a project that developed a unique product, service, or result that no none wanted? It's happened, you know. Even though the project team completed all the work proscribed in the project scope. Even though they finished on time and on budget. Even though they satisfied all quality standards. Still, no one wanted it. It couldn't happen to you? It could. It happens whenever there is a disconnect between business needs and what stakeholders may communicate they need. This disconnect occurs far more frequently than one might imagine. Successful project managers learn to recognize this risk and avoid or mitigate it. Unsuccessful project managers fail and take the blame. (Seriously, do you think anyone else is going to accept blame?)
A project that delivers an unacceptable result is arguably far worse than one that is cancelled or runs over-budget or over-schedule. By definition, the project is complete and the entire budget is spent. There is nothing left to fund a do-over; especially, not in a challenging economy.
How do project managers prevent such a result?
For those familiar with PMBOK®...
Progressive elaboration, as the Project Management Book of Knowledge (PMBOK®) defines it, is a technique for “continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available as the project progresses, and thereby produces more accurate and complete plans that result from successive iterations of the planning process.” Like most topics in PMBOK®, this is good information as far as it goes and depending upon how it is interpreted.
One cannot argue with the admonition to continuously improve and detail the project plan during successive iterations of the planning process. But, how about the principal product of the initiating process; the project charter? Should it be revisited periodically to insure that the major deliverables of the project will satisfy the real business needs of the sponsoring organization? Should it be revisited to insure that the project plan is on track to deliver a result that meets those needs?
The PMBOK® definition of the project charter does not include its content. It simply states that it is “a document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities.” However, in describing the process to develop the project charter it says, “It is the process necessary for documenting the business needs and the new product, service, or other result that is intended to satisfy those requirements.” We must then infer that these elements too should be found in the project charter.
Inasmuch as PMBOK® specifies that the project charter is an input to the planning process, it explicitly justifies revisiting the charter during progressive elaborations. Revisiting the project charter does not necessarily imply that it should be changed. Indeed, changes in the project charter will ripple throughout every aspect of the project plan as well as all subsidiary plans including the Risk Management Plan, the Staffing Management Plan, etc. Thus, charter changes should not be introduced lightly. However, care should be taken throughout the life of the project to insure that all stakeholders share a common vision of the business needs being addressed in the project, its plan, and its intended major deliverables and that the project is always on course to satisfy those needs.
For those not so familiar with PMBOK®...
Project managers must constantly challenge and check their understanding of the sponsor's intent in authorizing the project throughout its entire duration. What is the business need being addressed by the project and what are the criteria by which the major deliverables will be judged? Progressive elaboration is a process by which project stakeholders continuously monitor their shared understanding of the project and revise its plan as necessary to insure that the product, service, or result of the project will be accepted.
There is one person who can prevent progressive elaboration from accomplishing this goal; the gatekeeper.
Gatekeepers
Gatekeepers are people who control access to individuals and groups in an organization. Salespeople have been plagued by gatekeepers since the first Neanderthal tried to sell fire to a neighboring clan and was stoned by sentinels outside their cave. And, as every salesperson will tell you, it was their loss; that other clan really needed fire. Well, there are gatekeepers who keep project teams from gaining access to those with key information and insight necessary to the success of the project. They often keep the project team from collaborating directly with key stakeholders. Sometimes they function as a clearing house for input from other key stakeholders. In other words, they are holding themselves out as having all responsibility and authority for elaborating the project and its plan themselves.
Transferring responsibility for progressive elaboration from project managers and their teams to a gatekeeper is a prescription for disaster. Remember the exercise in school where the teacher lined up the class and whispered a secret message to the first person. As the message was whispered from one person to the next it was distorted until the last person heard entirely different than the message the teacher initiated. The same happens when gatekeepers filter the knowledge, needs, and advice of key stakeholders to project managers and their teams.
Keep in mind that all gatekeepers have some degree of influence or authority over the project; more so than the average stakeholder. They are generally superior to the project manager. Thus, they must be handled carefully.
Avoiding Gatekeepers
There are two principal methods of avoiding or mitigating the effects of gatekeepers; one using subtlety and the other brute force. Always attempt the former first and the latter when the first fails. In no case should gatekeepers be allowed to succeed in preventing direct contact between project managers and their teams and key project stakeholders.
The avoidance or mitigation strategy best employed most likely will be determined by the motivation of the gatekeeper. Some gatekeepers feel they need to filter all communications during the elaboration process because they do not trust other key stakeholders. Either they may feel that only they correctly perceive project goals and needs or that other input will lead the project team astray. Others may insert themselves into the role of gatekeeper because they do not respect the ability of the project manager to adequately mine the stakeholders for the required input. There may be cases where project sponsors mistakenly authorize the arrangement. Regardless, project managers must begin by developing a close relationship with the gatekeeper to ascertain their motivation and select the best strategy for avoiding or mitigating the risk they represent.
Googling “getting past the gatekeeper” will provide tens of thousands of links to web pages offering good advice for salespeople. Interestingly, many of their strategies and tactics can be applied to project teams who encounter gatekeepers. Ultimately, the best advice is found at the top of most lists: “Turn Gatekeepers into allies: treat them with respect, humor, and compassion. Their jobs can be tough, too. They get it from both ends. Regard them as people with their own personalities, not as faceless obstacles to overcome at all costs.”
Gatekeepers who lack trust in their associates may be best handled by inundating them with tasks to the point that they will be forced to delegate them to others. This will either prove to the gatekeeper that their associates can be trusted or to the project manager that they, in fact, cannot. Testing and evaluating early project activity and phase deliverables provides an excellent opportunity to employ this tactic.
Gatekeepers who lack trust in project managers and their teams may come around, if they are reasonable, after the team has had an opportunity to demonstrate its competence in the early activities and phases of a project. If the gatekeeper continues to insert themselves into the process to the detriment of progressive elaboration, it may help to arrange demonstrations of the effects of their behavior during general project meetings. Hopefully, the gatekeeper's interference will be perceived and someone in authority will take corrective action. Failing this, the project manager may have to escalate the issue to someone superior to the gatekeeper for resolution. Remember, once this tactic is chosen there will be repercussions. Do not embark on this path lightly.
The most difficult situation to reconcile occurs when a project sponsor designates a gatekeeper. They won't be known by that title but they will perform the function. In effect, the sponsor is ignorant of the project manager's role in this regard or, worse yet, they lack confidence in the project manager's ability to perform it. Dealing with this situation takes great patience and finesse. Project managers may be able to educate the project sponsor or demonstrate the problems being created by their poor command decision. Granted, the odds are stacked against success. However, failure to correct the situation is bound to end in an even greater disaster.
Conclusion
Gatekeepers may be encountered in any type of project and represent the same risk in all making this a subject worthy of further discussion and study. It would be helpful if others shared their experiences with gatekeepers in projects and their success or lack thereof in avoiding them or mitigating their impact.
About the Author
Jack Durish is the Interim IT Executive. He has more than 30 years experience planning projects, scheduling tasks, and managing teams in government and military operations as well as private industry. He is a creative problem solver with a proven track record of surmounting risks to complete projects on time and on budget.
Jack has helped organizations of all sizes including global ones discover and adopt creative technological solutions to real business problems. He has participated in every aspect of exploring emerging technologies, evaluating them, and deploying them. He has also aided in their adoption, training and motivating users to maximize the return on technological investments.
Jack is a skilled communicator. He is a published author of books both fiction and nonfiction as well as courseware and articles. He is an experienced lecturer in the boardroom as well as the classroom having mastered the ability to both instruct and persuade audiences of all sizes and types.
Visit his website at http://www.ironlantern.com/
No comments:
Post a Comment