Page 333 - Global Project Management Handbook
P. 333

16-20         MANAGEMENT OF GLOBAL PROGRAMS AND PROJECTS

           The matrix often features the power struggles between the project and functional man-
        agers. The key to solving this problem, or pathology, as some experts call it, is to choose
        a clear power-sharing mechanism between the two managers, train them to deploy it, and
        constantly reinforce it from the top of the organization. This mechanism has an impacts,
        therefore, on the decision making and resource support. For example, in one organization,
        the choice was made to have project managers own the VGS project and major project
        decisions about the project strategy, whereas the functional managers were seen as the
        providers of resources to support those strategies in multiple concurrent projects, which is
        quite a challenge. Choices about the triad may be different—which depends largely on
        the organizational culture and strategy—but once made, and whatever they are, their suc-
        cess will, to a great degree, hinge on how well they are deployed by the players and oiled
        by the top management.

        CSF14: Create a Cross-Functional Team Structure.  VGS projects are inherently
        cross-functional, involving collaboration of dispersed decision-making units.
        However, in order for all the interdependent modules developed by different sites to
        function as a seamless final product, a certain degree of centralization is also necessary.
        Success of VGS project depends on finding the balance between centralization and
        dispersion of the decision-making authority in the project. Therefore, clear roles of
        dispersed units and individual members are vital to VGS projects, as are good deci-
        sion making and skill sets of team members.
           It is crucial that decision-making protocols are clear. For that matter, the sixth
        strategic factor—the process—provides the mode for executing decisions among VGS
        sites, including the chain of command among the dispersed decision-making units. As
        one experienced VGS project manager noted: “Chain of command is a core principle,
        especially in large projects. We need to know who is responsible for making various
        decisions. I think collaborative decision making is a great thing, but you still have to
        have chain of command and a person who is responsible for seeing the decisions get
        made.” Based on the nature of the VGS project and the choice of management, the
        decision-making authority may be centralized, or balanced, or dispersed among sites.
        The choice made must be consistently deployed and unambiguously communicated to
        the VGS team.
           As for the members’ skill sets, having competent VGS team members is one of the
        key enablers of their success. Some of these skills are worth mentioning. For example,
        the team members have to have more than the needed technical knowledge. Given the

        separation that exists between the sites, team members also need to be excellent commu-
        nicators. They need to be aware of the ways that details can fall between the cracks and
        be very detail oriented to prevent that from happening. An experienced VGS project man-
        ager observed that “alignment of roles with personal qualities is important.” This stresses
        the importance of having the right people for the job.

        CSF15: Manage Stakeholder Expectations.  To be successful, VGS teams need to
        aptly manage their stakeholders—customers and the project sponsor primarily—and their
        expectations. First, the VGS team must know what customers want; this is of paramount
        importance. Note that assuming to know is unacceptable. If the team does not know the
        customer’s requirements, the project may be in danger, as the project manager of a VGS
        project noticed: “The offsite team was simply too separated from the customer. That is
        why what they came up with did not exactly reflect what the customer wanted. They
        failed to capture these wants in the requirements document, elevating our risks.”
        However, capturing the right customer requirements is not enough. The requirements
        may change during project execution for any number of reasons; therefore, staying in
        constant touch with the customer during that execution phase is a necessary practice.
   328   329   330   331   332   333   334   335   336   337   338