Development stages for large virtual projects
Virtual projects are a rapidly developing medium for project management. Determining what traditional methods apply will advance knowledge for future projects. What distinguishes a virtual project is the absence of a common worksite. Whether the project team is dispersed on different sites of the same organization or in different countries, the team does not reside together. Lacking face-to-face options for managing work, the project team must create the same success by imposing process structure and rigorous team management. Clearly some types of projects do not lend themselves to virtual implementation, but for technical and collaborative work by professional knowledge workers, virtual projects can capture the best ideas and produce results across physical space.
This paper shares insights into strategies and methods for managing virtual teams and ways to structure their activities as their work progresses through the project life cycle. To leverage transferable knowledge, project management is the central theme, rather than the products of the virtual projects. Attention spent on the variations that emerge from producing different products or services would dilute the transferability of the project management principles. Examples are taken from the transitions of an actual team in multiyear virtual projects. One project currently in progress, OPM3, is PMI's development of an “Organizational Project Management Maturity Model.” Both authors co-led 10 OPM3 development teams for eight months. Other prior projects providing source material were a virtual conversion of a high volume credit check system from the American continent for use in the European market (as early as 1990) as well as several software development, management improvement, information technology, and telecommunications systems projects.
Initiating a Virtual Project: Getting off to the Right Start
Two distinct levels must be managed in a large virtual project. The project itself progresses in predictable “phases” of initiation, planning, execution and control, and closure (PMI Standards Committee, 1996). The product's development “stages” are an overlay on that model, with each “stage” of concept development, design, prototyping, construction, testing and delivery extending over a longer or shorter portion of the overall project life cycle depending on the nature of the development effort and the number of unknowns.
Like any product, a large virtual project also goes through development stages. The design of a project, and subsequent selection of its life-cycle template, should reflect the phase bias of the project itself as well as the phase bias of the sponsoring industry. For example, R&D projects favor creative methods, dominant in the “initiating” phase. Development projects favor definition and compliance with requirements, dominant in the “planning” phase. Construction industries or maintenance projects favor configuration management and control, dominant in the “execution” phase. (Venture capital projects would, of course, favor closure.)
The purpose of a project life cycle is to find something common to all projects among all these differences (Bonnai, Gourc, & Lacoste, 2002). Virtual projects are expected to produce similar value and results for the sponsor, but there are unique challenges to creating and sustaining them. Sustaining momentum, building technical understanding, and designing quality assurance into the work process require separate planning and continuous management attention—built into the project schedule. Simply creating a project plan and distributing tasks to team members will not work, particularly if project participants represent different industries, job backgrounds, and technical experience.
Guiding a large virtual project through its stages requires skill and strong team leadership. Technological advances, tools and work methods available today allow development of projects that would have been a big risk a decade ago. It is not uncommon to have subprojects offshore, or part of the team halfway around the world. Teleconferencing, televised meetings, shared websites and transferable files certainly help. But technology alone will not suffice. Adept application of fundamental project management principles is what makes these projects work. The PMP®, and all it stands for, will carry a premium as virtual projects proliferate. When people contribute to a project from different disciplines, industries, and cultures, a common base of knowledge—such as the PMBOK® standard—leverage decision-making, knowledge, and the team's ability to deliver.
The profitability or payback period will need to be articulated and approved by management. Treat it as any other portfolio holding (Schlichter, 2002). Quantifying risks as well as expected returns puts the project investment in perspective. For some products, “time to market” links to the bottom line. For others, a failure can erode confidence in the sponsoring organization, even stock price. One company, sued for failing to meet delivery schedules on a systems development contract, experienced a one-third reduction in their stock price almost immediately, and a slow recovery after that (Filler, 2001). Clearly, the investment in a project is like any other investment: you put money into it expecting a return. “Informed managerial decisions and an organization's response time can be critical to both stability and financial health. More often than not, top management (or the board) is mandating…a conceptual plan to tie every systems application, every training program and every communication channel to the business imperatives of the organization, and processes that require that every initiative be justified and every renewal of old programs be assessed for continued value” (Cooke, 1988).
Once the decision is made to go ahead with the project, everything should focus on ensuring its ability to deliver. The right professionals, appropriate power and resources, a supportive organization infrastructure and the technical environment are as important to success as picking the right project manager. There are rare opportunities in the scope definition stage to establish the environment for project success. Strategic planning and project selection address the financial resources, but for a virtual project, tools are also critical. If the tools are not there to support a virtual team within the organization, put them in place!
Tools and Technology for the Virtual Team
During project initiation, appropriate support systems must be put in place. For a large project, establishing the right technical platform—not just for the product but also for the team—is crucial.
Organizations usually invest in project management tools, infrastructure, and talent when they determine that they either stand to gain by doing so or lose money if they do not. “One thing organizations are going to have to do is elevate the level of competence,” says project management expert (David) Frame. The first level of competence is individual, requiring formal training and PMI® certification (Filler, 2001). Recruiting and training fill that need. Recruiting fills the need for fundamental competence; training refines it to the needs of the project.
The project is usually in some stage of early scope definition when the project manager is engaged to get it funded or approved (Meredith & Mantel, 1995). In this stage, there are a few crucial “environment” issues to settle before developing the project plan. Initial planning deals with the strategic issues, identifying their effect on the master plan and schedule for delivery. The life cycle for the complete project must first be defined in order to apply the appropriate amount of structure in each phase to produce desired results.
Developing realistic schedules and creating credible estimates are a challenge. To estimate effort, historical data on similar projects is needed, and little is available. If your organization does not have “Meta Data” available (data about data relevant to the business), create a file of your own, noting conditions under which the data was collected (Gannon, 2002). The type of repository is less important than the content. How big were the budgets of similar sized traditional projects? What was the average percent of overrun? What was the average accuracy of initial duration estimates? What was the typical initial projected ROI if time to market targets were met? What have other organizations done in similar projects?
Since it is difficult to have a detailed view of latter phases when a project is just launched (Fleming, 1998), the early project plan is often made of “several overlapped coordination schedules covering the midterm. The first schedule covers the design phase, and helps procurement get under way while other work packages are being developed to bring specificity to the next stage of the project” (Bonnai, Gourc, & Lacoste, 2002). In the schedule, the ends of the phase are anchored and bars extend over that period to show the schedule in graphic form. Attempts to be more specific at this stage can invite rework. Roughly defined products become more fully defined as work progresses in the design stage. The cumulative interaction of the development activity will create more specific schedules. Since their purpose is control, they do not need specificity in the early planning stages.
Large virtual projects have a dynamic all their own that is seldom fully reflected in the plan. If there are lots of unknowns, the product will be iteratively forged, with even a series of subprojects, each adding specificity to the next stage of development. It may take a fractal approach if the overlapping interfaces for phases are fuzzy or responsibility is spread so that decisions become complicated (Bonnai, Gourc, & Lacoste, 2002). Prototypes may be used, or whole project stages run as a project to create the plan. If research and development is the intent, freedom from unnecessary structure (premature control) must be designed into the initial stages to capture the creative synergy and prevent a predetermined outcome. If the project is similar to others done before, following and refining a standard process is more important. In a virtual project it is important to design the project to deliver the desired outcome, then formally communicate its life cycle to the team and to the customer and sponsor.
The life-cycle template selected for the master schedule reflects the strategy of the project; it should cover the whole duration of the project from the go/no-go decision. If a risk-oriented project life cycle has been chosen, say so. Life-cycle models convey the “progress philosophy” of the project to promote better understanding and a better communication within the projects (Bonnai, Gourc, & Lacoste, 2002). Ambiguity in the design can be fatal if misconstrued by those carrying out the work or those funding the initiative. Communicate your strategy clearly.
Tools and Technology for the Virtual Team
Tools for communication need to be in place before the team begins work. Technical materials are fundamental to the team's ability to generate useful work products. The technical environment should provide the means for online document review, interactive meetings, training, discussion threads, research and survey data, benchmarking, quality review, data collection, and reward systems for sustaining team commitment. Tools should include your company's internal options or:
• Project scheduling and tracking tools (a common platform or “MS Project” equivalent)
• Central communications (database and document libraries, or an “Intranets.com” equivalent)
• Survey tools and requirements management tools replacing face-to-face contact (OPM3 uses Zoomerang)
• Work templates and process descriptions (for generic, try public websites)
• Standards for project management and for work production (methodology, key references, agreed-upon terminology—consistent with training): PMI's A Guide to the Project Management Body of Knowledge
• Program management files (“Intranets.com” equivalent)
If the organization's larger infrastructure does not contain the tools to capture, share and reference key documents, then the project team should develop them within the communications plan for its own use. If the project cannot arrange the proper technology, put it in the risk plan for management signoff.
Project Planning and Setup: Preparing to Do Business
Project planning of course includes creating the traditional aspects of the project plan, schedule, and budget, controls and support services. But it also includes planning the management aspects of the project itself. These include:
• Quality management (metrics, collection points, data use policy, tolerance ranges with database)
• Online training with 24-hour access for offshore development projects—try packaged programs (Jain, 2002)
• Self-instruction materials (project and product descriptions from vendors, or documents from project initiation)
• Support staff and external sources of help (internal support, subscriptions, consultants, trainers).
If a virtual project takes seriously the job of managing expectations, then all stages of the project become an analytical exercise in creative group management. Virtual projects often require complex decision-making. Building and sustaining customer involvement, and delivering on expectations, are part of today's definition of quality. Some virtual projects will assign team members to be a liaison with specific individuals in the sponsoring organization to ensure support and head off problems. Also schedule a regular cycle of briefings with the customer to get their advice. If they are involved in determining how to handle exceptions and issues as they arise, any problems that do arise will not be a complete surprise.
Organizing and Managing the Team
Team activities, including communication activities and decision points, will need to be inserted into the schedule. The project team is the bedrock of the virtual project. Although there are probably 10 small projects to every large one, few organizations today have the luxury of calling a technical professional with a “to-do” list a project as they did 10 years ago. Involving team members offers a defense against narrowly defined outcomes. Diverse points of view help to manage the risk of overlooking critical aspects of the product. Though diverse teams and differing points of view are harder to manage (Hanna, 2000), involving team members in key decisions allows them to shape the outcome and builds ownership. Waiting until there is pressure or few real options creates divisiveness and exaggerates differences among the individuals involved (Hermann, 1986).
Training is also important to the team, since in complex projects the learning curve can be steep. Kickoff meetings and “level-set” training on project concepts need to be placed in the schedule at key points by phase. Recruiting the right talent, deploying knowledge where it can do the most good, using team members at full performance, and retaining knowledge within the team are fundamental to project success.
Recruiting the right professionals is critical. Lead team members exhibit the values emulated by others. “Shared values are the ‘glue’ that hold the virtual project community together, “ according to Robert Ferguson, former process lead at McDonald's SEPG in Illinois USA. Leadership and management are a shared responsibility across the team. PMI's collection of handbooks, Principles of Project Management, lists the key characteristics of the developmental leader (Adams 1996, p. 107):
• Willingness to manage
• A positive orientation to people
• The skills to communicate mission and purpose (often repeatedly)
• A decision-making technique that builds commitment
• A leadership profile that builds support.
A sincere interest in the achievement of the team as a team is conveyed subtly through all media. The project manager must have real leadership characteristics to succeed in managing virtually. The project manager's ability to select, train, manage and retain a quality team is a critical success factor in the virtual project environment. David Frame is quoted in an article about large technical projects at AT&T: “Project managers also must be competent in leadership and business skills…They're really the CEO of a tiny enterprise, no matter how small the project. They're not just mere implementers like they used to be” (Filler, 2001).
Key Roles and Succession Strategies
Ideally, the people who start into a new virtual project stay with it until it completes its mission. For large projects, ensure continuity of leadership with a second tier leader behind each team lead. Plan to allow voluntary transfers to other roles on the project, particularly at the end of stages. The rate of change that occurs within the project means a person's role evolves as the project evolves. If that is not enough to ensure people continue to develop, let them shift to another role. Experience that stays on the project can be leveraged in each successive phase.
The project seldom lasts long enough to “educate” team members; usually the focus is on leveraging existing knowledge, skill and performance. That means the project manager needs to dig out that knowledge. For team leaders, use one-on-one exploration. Within a large team, monitor who is underutilized, who is overworked, who is unsure of their role or value in the assignment they are currently performing. Take action to keep the team. If you doubt the value of retaining a team member, add the cost of training, the lost productivity while new people gear up, and the cost of having things done incorrectly.
Because the project differs from the organization each team member worked for, the project needs its own structure. Whereas behavioral exercise of power establishes some of the reporting structure in traditional projects, written job categories and the organization chart communicate authority to the members of the virtual team. Generic “job categories” need to be established up front: manager, technical lead, business/process/technical analyst, and program support. Define the details later. The new team member finds familiarity in these common roles, adopting their expectations for performance, standards, and a path for “advancement” within the project over time.
Turnover and Training
Turnover is inevitable, and new people need to be brought up to speed on the project as well as the product. Since the traditional informal mentoring and training options are less accessible, formal mentoring assignments and formal training events are important. Training obviously cannot fill education gaps. For effective performance, the project must bridge the gap between knowledge brought onto the team by a new member and the desired level of daily performance. Level-set training needs to be “administered” like medicine whenever lack of agreement on concepts causes delays. Put this training online where people can get it any time of day, usually on the shared website.
Recognition and Reinforcement
A positive work environment must be nurtured for team retention, but the pace of project work is too fast for organizational recognition and reward. A self-sustaining peer recognition system can be implemented with a certificate, ground rules, and a process for claiming prizes. Posting winners’ names on the common website also boosts morale. Of course, the best recognition for any worker is to notice and praise a job well done—citing how it contributed to the project as a whole.
The greatest problem in communications is the illusion that it has been accomplished, according to Daniel Davenport (Gannon, 2002). Virtual projects rely on continuous communication. A formal communication plan created during project planning is refined and put in play during execution, with revisions and “off-line” telephone calls to clarify, reorient, reinforce and reassure the team. Putting contact information on documents, distributing team member lists, listing phone contacts at the end of emails and providing alternate contact numbers can make problem solving easier. Schedule a periodic survey of team members’ satisfaction with the amount and type of communications they receive to focus team attention where it will generate better performance.
Project Plan Execution: Putting the Virtual Structure Into Play
Assuming all the strategy and project design have been converted to technical reference documents, there are still secondary elements in the execution phase that take on an exaggerated significance if not carefully managed. The PMBOK® Guide (PMI, 1996, 2000) refers to these as “facilitating processes.” In a virtual project, the project manager will probably spend more time facilitating than directing.
Group dynamics also takes on more importance in a virtual environment. People from different company backgrounds and industries will have different work styles and norms, causing dissonance. Conscious creation of empowered, performing teams is a key task up-front during project execution.
Honest accountability and professional work habits form a cornerstone of quality in virtual projects. Team mentoring and mutual support must also be a norm. The fast pace of work requires rapid diagnosis and quick solutions to move forward. Frank identification of issues should be rewarded and internal competition squelched from the top. If problems are brushed aside rather than surfaced, by the time those problems are detected, it may be too late to recoup. Unless the project's host organization is totally “projectized,” the team members have a line reporting relationship with some manager outside the project. The “new” performance values will need to be established if this competing line of authority is not to dominate team behavior.
Establish and reinforce a new “team dynamic”—and do it quickly. When a new team member comes on board, for a short time he or she is open to learning what is expected. Old habits temporarily “unfreeze.” Unless new patterns are offered, the old ones are called back into play. If negative behavior arises, confront it privately and swiftly.
Senior professionals want to exert their own knowledge, contribute to group norms, and put their unique stamp on the deliverables and outcome of the project. The project manager and leadership team must provide involvement plus public recognition for the desired values and behavior, so that other team members can adjust to the new project's culture.
Retaining the team once it is trained is critical. Existing team knowledge and ability to perform is a resource more valuable than a simple line item in a budget. Seeking out each project team member's career goals helps in making assignments. Periodic “surveys” of the team's satisfaction with technical supervision and overall direction have provided useful information to create a positive work environment for each team member where possible.
Sharing Knowledge and Technical Material
The definition, assignment, and completion of work packages require advance planning—as well as careful synthesis and integration—for quality project results. Forty-two percent of computer knowledge is in everybody's heads, according to David Marco (Gannon, 2002). If a structure for capturing, retaining, and redeploying project knowledge is established, the team is empowered to self-manage to defined standards and desired outcomes. Team access to the work of other concurrent development activities, and the decisions underlying them, helps integration proceed smoothly. For the product, keep the latest versions of documentation accessible around the clock, such as on an intranet site. This allows the team to use up-to-date refinements in each other's work.
Documentation needs to continue during execution, building on the general documentation created during initiation and planning phases. For the product, define work products and deliverables to include input/process/output requirements, acceptance criteria, definitions of quality and any tradeoff priorities. Providing formats (such as templates) enhances productivity and provides a place to capture improvements and prevent wasteful rework. Simple flow diagrams speak louder than words. Ask the people doing the development to define what they are developing; ask those receiving their work products to refine the acceptance criteria.
For the project, create a central project manual in electronic format that explains the project's approach. Use the PMBOK® categories as a table of contents. As the project clarifies its operations, paste these decisions into the manual. Include elements of the project charter and operations policy, as well as:
• Project Management Tools, templates, standards, and the life cycle (what version, where to locate it)
• Communications channels, frequency of meetings, team member responsibility, and guidelines
• Administrative procedures, locations for templates, website headings, teleconference setup, time zones for all team locations, best times to set meetings, and any accommodations to the local culture (religious holidays, for example).
Identify issues and problems by various means. Include a section in meeting agendas for surfacing issues, and a website location for capturing them. Let the team resolve what it can, applying solutions as issues arise. For persistent issues, use the issue log. Assign a team member to brief the team leaders on their status. Issues typically cannot be resolved at their level of impact, or they would be. If the time is not right, wait. If the level of authority rests higher in the organization, the project manager takes it higher for resolution. The effect of issues on the schedule also needs to be revisited periodically to place them in their true light of urgency for resolution.
Many projects are risk driven. A risk management plan that quantifies identified risks by likelihood and impact helps the team focus on risk avoidance in their work, and risk mitigation where avoidance does not resolve the challenge. Some projects define quality—not time or cost—as their major risk, putting rigorous quality assurance processes in place. Peer reviews, while expensive, can find defects and remove them early in the development cycle. Use them for key deliverables. The result is not just reduced rework, but faster delivery and improved customer satisfaction. Training is necessary for team-based reviews, however, to ensure they are not misused, eroding morale.
Quality is designed in, not inspected in. The execution phase uses the quality infrastructure created during project planning. A 360- degree view of your customer using Meta Data…creates access to significant information on your customers (Gannon, 2002). Selection of the proper life-cycle template, project manager, and tools will have already made a significant contribution to quality assurance, put in place during project initiation. Discussing, documenting and refining work processes and sharing them with the team contributes to quality. The remaining quality tasks are peer reviews, quality plan reviews, process reviews, and reiterations of standards or policy. Monitoring compliance with established criteria works if those being monitored were involved in setting the criteria. In a virtual project, quality “police” can do more harm than good.
Most of us have been practicing configuration management for more than a decade, some longer. “Baseline” is configuration management applied to a project schedule. Version identification and update logs prevent inadvertent use of earlier (inferior) work products. Including configuration control in the quality management monitoring process can identify weaknesses in team practices and ensure final products are ready for use. Assign team members to configuration management. Train your team by rotating that role.
Taking the time to capture lessons learned and feed them into the organization and the future project reference repository helps the next project to get off to a good start. Save copies of deliverables and project templates, metrics and best practices. Route copies to others so they do not rest in a file unnoticed. Congratulate the team. Celebrate closure and publicize you are done. Hand the project off to operations or maintenance. Disband the team.
Quantifying project parameters and leveraging lessons learned during the closing phase can make the difference between a single successful virtual project, and a series of repeatable successes over time. We appear to have plenty of room for improvement: The Gartner Group projects 75% of e-business projects will fail to meet business objectives in 2002. IT projects have a 28% success rate and only 25% of Telecom IT projects succeed (Filler, 2001).
It all boils down to good management. While we change the names and buzzwords to generate temporary interest in good management, the virtual project relies on constant use of project management principles and practices. One vendor, when asked the single key suggestion he might make to ensure success in virtual projects, cited project management methodology. Without a methodology or standards, the members of a virtual project team are secondguessing expectations. With defined methods, rigorous team management, and facilitating processes, a large virtual project can proceed to a successful conclusion.
Adams, John R., C. Richard Bilbro, & Timothy C. Stockert. 1996. “An Organizational Development Approach to Project Management.” Principles of Project Management. Upper Darby, PA: Project Management Institute: pp. 89–103.
Bonnai, Pierre, Didier Gourc, & Germain Lacoste, 2002. The Life Cycle of Technical Projects. Project management Journal, 33 (1), March.
Cooke, Helen S. 1988. Information to Manage the Business: Our Competitive Edge. Deloitte's International Publication, UPDATE, 2 (4), p. 1.
Filler, Susan McNeice. 2001. Project Failures Spur Management Back to Basics. Billing World and OSS Today Magazine, November.
Fleming, Quentin. 1998. Proceedings. Project Management Center of Excellence. McDonalds Corporation, Oakbrook, IL USA.
Gannon, Patrick. 2002. Building and Managing the Meta Data Repository. End-to-End Integration Strategies and Solutions, Business Integration Conference, Brainstorm Group and GIGA Information Group, Chicago Hilton USA.
Hanna, Magdy, & Helen Cooke. 2000. Peer Review and Inspection Techniques for CMM. United Airlines ISD/PESG, Elk Grove Village, IL USA.
Hermann, Ned. 1986. Applied Creative Thinking. Charlottesville, VA: Ned Hermann Institute.
Jain. Anil. 2002. Conference Proceedings. Panel: BPI/BPM Solutions. End-to-End Integration Strategies and Solutions. Business Integration Conference, Brainstorm Group and GIGA Information Group, Chicago Hilton USA.
Meredith, J., & Mantel, S. 1995. Project Management: a Managerial Approach, 3rd Ed. Chichester, United Kingdom: John Wiley.
PMI Standards Committee. 1996. A Guide to the Project Management Body of Knowledge. Upper Darby, PA: Project Management Institute.
Schlichter, John. 2002. Unpublished Paper. An Introduction to the Emerging PMI Organization Project Management Maturity Model. 2002 European Conference, Berlin Germany.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA