Abstract
As project managers, one of our greatest challenges is bridging the communication gap with the technical team in order to gain critical insight into technical progress. At times, it seems that the project manager and technical team speak different languages. The question, “Is the task complete?” elicits different responses depending on how the respondent defines “complete.” This paper introduces a communication framework that facilitates discussion between a project manager and the technical team members on matters of technical progress. It then shows how to apply the communication processes from the Project Management Institute's (PMI®) A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition to set up the framework for your project. Finally, it presents common miscommunication scenarios and explains how the communication framework can be used to overcome the communication gap between the project manager and technical team.
Introduction
As project managers, one of our greatest challenges is bridging the communication gap with the technical team in order to gain critical insight into technical progress. We are expected to balance the triple constraint (i.e., cost, schedule, scope), and we must meet the customer's requirements within the agreed-upon cost and schedule. To address scope, technical reviews are scheduled as major project milestones. Information from these reviews feeds into programmatic reviews, which are held to assess technical progress against cost and schedule. Tools such as earned value are frequently used to communicate progress in these areas. Unfortunately, there is no standard tool for measuring and communicating technical progress, so the earned value measures are often inaccurate. This is why we often see projects reporting “90% complete as planned” with very good cost performance index (CPI) and schedule performance index (SPI) values only to discover that the project is way over budget and delivers much later than expected. The lack of insight into technical progress is often the result of miscommunication between the project manager and the technical team—they simply do not speak the same language.
There is communication guidance available to project managers, including the A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition, (Project Management Institute [PMI], 2008). The communication management processes in The PMBOKi® Guide—Fourth Edition identify the activities needed to “ensure timely and appropriate generation, collection, distribution, storage, retrieval, and ultimate disposition of project information” (p 243). It is the responsibility of the project manager to execute these communication processes, but there are few details as to how to make them successful: How can the project manager extract the appropriate level of detail from his or her technical team? Does the project manager need to become fluent in the technical language? Does the project manager need to know all the intricate technical details of the project? All too often, project managers find themselves in the following situation:
Project manager (PM): Are we on track to meet our deadline?
Technical lead (TL): Yes, we are on schedule to make the deadline.
...Four months later...
Project manager: The customer will be here next week for the demonstration—are we still on track? Technical lead: Actually, we had to make a switch from widgets to gidgets, and I'm still waiting for our gidget developer to finish up his other project. So, we won't be ready for a demonstration next week.
For too many companies, this scenario is not uncommon—technical progress is assumed to be on track only to find out very late in the project life cycle that an issue has occurred requiring more resources (e.g., staff, equipment). Most of the time, the problem is not purely technical even though it may seem so in the eyes of the team. More often, the problem has non-technical aspects that could have been addressed with management action, such as reallocation of staff. Understanding these problems does not require the project manager to be fully versed in the technical details of the project, nor does the technical team need to be concerned with the programmatic issues. However, the two need to communicate clearly, using the same language and underlying context.
In this paper, we describe a communication framework that project managers can use to communicate with their technical teams to bridge the gap between technical details and management concerns. The framework provides a structured way of communicating that both the project manager and the technical team use to discuss progress in meeting project scope, increasing the project manager's effectiveness in addressing non-technical issues that may negatively impact technical progress. Using the five communication management processes in the PMBOK® Guide—Fourth Edition as a template, we provide the following:
• A brief history and explanation of the framework,
• Details on how to use the framework as part of daily communication on your project,
• Common examples of communication issues within each communication management process, and
• Ways to use the framework to overcome these communication issues.
The framework can be used throughout the project life cycle to facilitate communication between all project stakeholders that can be used throughout the life of the project.
Communication Framework
The communication framework is based on Philippe Kruchten's Software Architecture 4+1 Model (Kruchten, 1995). This model has been adapted by others for use in determining system technical progress and quality (Ferguson, Fowler, Creel, & Boyd, 2009), and we have expanded this work to show how the framework can be used as a communication tool. The framework is based on the premise that project progress should be examined by answering questions from the perspective of various stakeholders.
While the project manager is concerned with the triple constraint, he or she receives information about scope from his technical team. Exhibit 1 depicts this relationship.
Exhibit 1: Triple constraint with inputs from technical team
The problem with the relationship in Exhibit 1 is that scope is the least concrete of the triple constraint. Cost and schedule are definitive and quantifiable. Scope starts out as a set of high-level requirements, but insight into technical progress toward meeting these requirements is much more difficult to obtain with confidence. Current methods of communicating technical progress are highly subjective and lead to inaccurate pictures of progress. In many cases, the technical details of the project are in place (e.g., requirements approved, design validated), but there are non-technical issues adversely affecting technical progress. These non-technical issues, such as needing an unavailable subject-matter expert, are often not addressed early enough to prevent impact on cost and schedule.
The proposed communication framework provides a method for adding rigor to communicating both technical progress and the non-technical issues that may be impacting progress. Exhibit 2, which is a variation of Kruchten's software architecture model, shows four views and questions regarding scope that cut across the views to provide a holistic technical picture.
Exhibit 2: Stakeholder views and cross-cutting questions about scope
These four views represent various stakeholders in technical progress:
• End user/customer is concerned with system functionality and ensuring that the functional specification aligns with intended use of the system,
• Systems engineer/architect is concerned with the functional and non-functional requirements that the design must address and ensuring that the design meets required quality attributes (e.g., performance, security),
• Developer is concerned with creating system modules to meet the design and having the correct number and skill set of team members and other resources, and
• Maintainer is concerned with system deployment and how to install and administer the system once it is delivered to the end user.
The scope questions bubble in the center of Exhibit 2 represents any questions that the project manager asks of the technical team with regard to technical progress towards meeting project scope. The technical note by Ferguson et al. (2009) details a formal approach to using the 4+1 views during technical review meetings; we refer you to that paper for information on tailoring the framework to conduct technical reviews. We propose that project managers employ this framework in their regular informal communication with the technical team.
The communication framework requires that the project manager consider all four views when asking the technical team for information on technical progress. In the scenario provided in the Introduction, the project manager asked, “Are we on track to meet our deadline?” Using the communication framework, the project manager would instead break that question into four more specific questions as follows:
• Will we have all functionality ready to demonstrate by the deadline? (end user)
• Are there any issues preventing us from meeting our Technical Performance Measures (TPMS)? (architecture)
• Do you have all staff resources required to meet the deadline? (developer)
• What equipment is required to prepare for or run the demonstration? (maintainer)
These questions are intended both to provide confidence that the technical work is progressing as planned and to discover non-technical issues that the project manager can resolve before they impact the technical work, cost, or schedule. This method of communication requires both the project manager and the technical team to consider multiple views of the project, and it trains both parties to anticipate the types of questions and examine the project from these alternate views while performing all project tasks. The project manager no longer relies solely on the technical team to provide information on technical progress, but rather steps into the roles of the stakeholders via the four views.
In the following sections, we provide an overview of the communication processes from the PMBOK® Guide— Fourth Edition (PMI, 2008), detail how to set up the communication framework for your project, discuss common miscommunication scenarios, and explain how the communication framework can be used to bridge the gap between the project manager and the technical team.
Communication Processes: Identify Stakeholders and Plan Communications
Setting up the Framework
Tailoring the framework for your project is performed during the identify stakeholders and plan communications processes in the communication management focus area of the PMBOK® Guide—Fourth Edition (PMI, 2008). During these processes, the project manager identifies all entities that are positively or negatively impacted by the project and then plans how to communicate them over the life cycle of the project.
Establishing the framework entails identifying who is represented in each view on the project; this may be a group of people, a role, or a specific individual. The end user may be a bank teller who will use the financial software that your team is developing. The architecture view may represent the systems engineers who will design a system that meets architectural requirements for performance and security. Some views may represent multiple technical stakeholders—the maintainer view may represent the system administrator who will perform daily back-ups, and it may also represent the logistics team who will perform yearly system upgrades.
You should tailor and review the framework with your technical team to personalize the views for your project. By personalizing the framework, your team will more readily relate to the stakeholders. If you ask your team to think about “an end user,” they have a vague picture in their mind of who might use their product that is generally biased by how they imagine the product should function, but if you ask them to think about “Jane” whom they met at the customer site during the kickoff session, the picture in their mind solidifies and they can imagine how Jane plans to use the system based on the specific job overview she gave them. Personalizing the framework is also important so that everyone understands not only who the views represent, but also what their primary concerns are.
For example, the bank teller is not concerned with the design details of the system, but is very interested in having an intuitive human-machine interface (HMI). Reporting progress to this end user may involve an update on how many graphical user interfaces (GUIs) currently meet the customer standard as opposed to reporting that 45 percent of the expected software lines of code (SLOC) have been written. However, the developer is very interested in knowing how many lines of code have been completed. Both of these are valid technical concerns, but rarely are they both addressed when discussing technical progress. The communication framework teaches both the project manager and the technical team to consider all four views when communicating technical information. This, in turn, provides a much more accurate indication of technical progress.
Using the Framework
Once the framework has been tailored for your project, it can be used in all communications with your technical team. While effort is required to establish the framework, once implemented, both you and your technical team will begin to consider naturally the four views when discussing technical details. A common issue between the project manager and the technical lead (TL) is determining which technical details need to be discussed. The project manager cannot be involved in every technical decision, such as which standard library to use in the code. Likewise, the TL cannot be expected to handle the non-technical issues that may impact technical progress such as borrowing a subject matter expert from another project. There is a delicate balance when determining when and what to communicate.
For example, one day your TL is talking to the customer's TL, and they determine that it would be better to write a piece of code in JAVA than in C++ as planned. To them this seems like their call, and they go ahead and begin to put this change into place. At the next team meeting, your TL mentions offhand that they decided on this change in direction and “it's no big deal.” You consult your schedule and ask this very important question, “Are you still going to be able to do it on schedule in three weeks?” Your TL gives you a little smile, all the while chuckling inside about how obvious it is that you have never coded before, and says, “Yes, it doesn't take any longer to code in JAVA than in C++.” At this point, most conversations like these end. But did you and your TL really communicate? Is the coding really going to be finished within your three week schedule? Even if the schedule is met, what other impacts has this decision had on the project? We refer to the framework to improve the conversation.
TL to PM: We decided to write that component in JAVA rather than in C++, no big deal.
PM to TL: Sounds like an interesting idea, I have a few questions:
• Will you still be able to provide the seamless integration with the touch screen hardware? (end user)
• Does JAVA introduce any security holes? Have we accounted for extra time to code around those holes? (architecture)
• Does Jamie have JAVA experience or will we need to make a staffing change? (developer)
• Have we asked whether the customer's IT department is prepared to manage changes to JAVA code? (maintainer)
Through these questions you will uncover important non-technical issues that require management attention, such as the need to get a different developer and how that impacts the schedule or the fact that while writing the specific component code takes the same time in either language, adding in the security on that component will increase the schedule. In the beginning, training yourself and your team to communicate in this manner may seem burdensome; however, as time goes on this will become second nature and will flow easily.
Next, we will turn to the communication process we use most throughout the project life cycle.
Communication Process: Distribute Information
Common Miscommunication Issue
Distribute information is the key process area for communications: It is here that the majority of our projects take place, and it is here that we can make a project successful or doom it to failure. The goal of this process is that all parties receive all relevant information in a time and format that allows them to take the necessary actions. One of the most common errors in this process is misunderstanding the appropriate level of detail for the audience. For example, some customer project managers focus at a very high level and want what would be considered “executive level” information, others have a deep technical background and want to understand the nuts and bolts of the system. It is only through a little bit of trial and error that we will discern exactly where each person stands on this spectrum and be able to tailor his or her information appropriately.
Let's assume that your customer has a deep project management background and understands the need to balance information between the two poles described above (executive level and technical depth); it is at this level that they want to receive information. You are preparing your presentation for an upcoming program review. You plan to present the cost and schedule details and you have asked your TL to present the technical status of the project. Your TL comes back to you with 20 slides depicting each system component and intending to brief every interaction shown. You need to coach your TL on the appropriate level of detail for the audience. This can be more difficult than it sounds because your TL is so engaged in the details of her design that she may have a hard time understanding what is relevant to your customer … after all, to her this is critical information!
Mitigation Technique
The communication framework was populated with the names and overall concerns of the stakeholders of the four views during the identify stakeholders process. We return to the framework for the distribute information process to help us work with the TL to determine the correct level of detail for the upcoming program review. Using the 4+1 views, the first step is to identify the scope question that you wish the TL to answer. When phrasing this question, ask yourself the following: “What is the purpose of the upcoming program review?” “What technical details are pertinent to the programmatic information that I will be presenting?” “What level of technical detail is required/has been requested by the customer project manager to meet the purpose of the review?” Rather than making the generic request that the TL present “technical status,” you should provide more specific guidance based on the answers to these questions.
For example, if you are going to report that the project is currently running overbudget due to a recent issue with a gidget, the customer project manager will want to know both programmatic details on impact to cost and schedule and the impacts of the issue to the product being developed, which the TL will provide. It is your responsibility to work with the TL to ensure that his slides address these concerns.
PM to TL: We are having a program review in two weeks. I am going to be presenting the programmatic impacts of the gidget issue. Would you please prepare and present no more than three slides that address the following impacts of the gidget issue:
• Any impacts to system operation such as HMI changes or hardware updates (end user),
• Any impacts to external interfaces or performance (architecture),
• Any changes to essential personnel or other resource needs such as software licenses (developer), and
• Any changes to logistics or maintenance plans (maintainer).
The idea is not to hide technical information from the customer project manager by limiting the number of technical slides. On the contrary, the goal is to highlight the technical details that are most important to the customer at the present time.
Communication Process: Manage Stakeholder Expectations
Common Miscommunication Issue
The managing expectations process is similar to distributing information. However, while distributing information is considered to be carrying out the communications management plan, managing expectations deals with unplanned circumstances where we must communicate issues to stakeholders or meet the stakeholders' changing needs. For example, we have all been in situations when the customer wants to shorten the project schedule, and we have all been pressured by executive management to figure out a way to satisfy these requests, however unrealistic they may be. It is in the manage expectations process area that we must determine how to work with the TL to identify the impacts of the request without having the rest of the technical staff quit from impending overtime demands!
Mitigation Technique
A key technique for this communication process was presented by Rick Morris (2008). Morris outlined a tactic explaining that the best way to help your project is to always say “yes” to requests—after all isn't “yes” what everyone wants to hear?—and then follow up with a statement of what you will need (e.g., more time, more money, reduction in scope), in order to meet the new requirement. We take that idea one level further in that the way you describe the impact of the changes to your customer is not via straight cost and schedule discussions, those are areas where the customer still expects to hear “yes,” instead it is by walking them through the framework and describing the impact in each view.
In this instance, the scope question has been posed by the customer, so we need to address the four views. The discussion with the customer will sound like this: Yes, we can deliver the product two months early. Here are the impacts:
• The product will not be able to meet the requirement for automated updates (end user),
• The product will only process 1000 updates/hour rather than 2000 updates/hour (architecture),
• We will need to pull developers and testers from your other product development activity to meet this deadline (developer), and
• Daily back-ups will need to be performed by a system administrator rather than being automated (maintainer).
Your project may have any combination of impacts across the views. The important thing is to consider the impacts on each view to manage stakeholder expectations.
Communication Process: Report Performance
Common Miscommunication Issue
In report performance, we provide a means for stakeholders to regularly review actual project performance versus the baseline established during the planning phases and make corrections where required. Unfortunately, while cost and schedule baselines have expected values that can be determined objectively at interim project milestones, determining technical progress at interim milestones is much more subjective. Reports on project performance areas such as earned value, risk, issues, change requests, and summaries of work accomplished are far from exact and are sometimes quite inaccurate.
As mentioned earlier, earned value is a key output of performance reporting. Earned value results are only as good as the data used in our calculations, and if we are not truly communicating with our technical team then our earned value will not be accurate. Have you ever noticed that when you ask your technical team their percent complete, you get results leading up to 90 percent at a steady rate, and then when you hit somewhere around 90 percent to 95 percent, you tend to stall there indefinitely? If earned value calculations are based solely on these inputs, they will be as inaccurate as the 90 percent complete number received from the technical team for months on end. The problem is that “percent complete” inputs do not present a comprehensive view of technical progress.
Mitigation Technique
The communication framework's four views help to provide a holistic picture of technical progress, which enables a more accurate estimate of completion percentages for earned value. To get this picture, we need an approach to quantify our assessment of technical progress, similar to the way cost performance index (CPI) and schedule performance index (SPI) values indicate programmatic progress. While no widely accepted indicator for technical progress exists, the technical note by Ferguson et al. (2009) described a graphical indicator can be developed using the 4+1 views. To generate this indicator, it is necessary to do more than simply address the concerns of stakeholders in each view. We must also define expected values and score how well the project is meeting the expected value for each view. Reporting technical performance using the 4+1 views requires a number of preparation steps including:
1. Determining at which milestones in the communications plan you will produce a graphical indicator,
2. Developing scope questions for each milestone,
3. Developing questions in each view that address the scope question, and
4. Developing scoring criteria (normalized to a scale of 0–10) for each question.
At each milestone, you and your TL will use programmatic and technical deliverables (e.g., requirements specification, architecture diagrams, test procedures, logistics plans) and conversations with the technical team to score responses to the questions in each view. Note that the level of detail for the questions will vary by view and milestone. For example, at very early technical milestones the end user and architecture views may have very specific questions while the developer and maintainer views will be more general and related to planning. However, it is very important that you consider all of the views during each phase of the project life cycle to ensure that all stakeholders' concerns are being addressed and to help identify potential issues as early as possible.
Let us say you are preparing for a critical design review (CDR) on a software development project. One of the scope questions that the customer will have concerns system performance. You and your TL will walk through the views to address performance from each view. Examples include:
• Are we on track to meet system performance goals/requirements? (scope question)
• Does the system operate according to the functional specifications? Any operator impact? (end user)
• Are all interfaces defined? (architecture)
• Are staffing levels sufficient for coding to begin? Is all equipment in place? (developer)
• Are site visits underway to assess network needs for installation? (maintainer)
You and the TL will score the answers to these questions based on expected values (these expected values can be planned well in advance when the framework was set up during the identify stakeholder and plan communications processes). All scores should be normalized to a scale of 0–10. The results can then be depicted as a diagram like the one shown in Exhibit 3.
Exhibit 3: Graphical indicator of technical progress (Ferguson et al., 2009)
Exhibit 3 is a way to show quickly where the project is and is not meeting expected system performance goals. In this example, the scope question scores rather low, and it is noted that the areas of concern are from the perspective of the system engineer (e.g., Interface Control Document may contain a high number of of fields marked To Be Determined) and from the maintainer (e.g., software installation details are not documented in draft form). This method not only provides both a comprehensive picture of technical progress and information on where management action is needed to get technical progress back on track.
Summary
The communication framework described in this paper is a tool for establishing and executing a communications plan that bridges the gap between the project manager and the technical team. The framework uses four views to address scope questions—drawing out areas that need management action as early as possible in the project lifecycle. When extracting information on technical progress towards meeting project scope, it is critical that the project manager consider the project as the integration of concerns from multiple stakeholders and encourage the technical team to think broadly as well.