Project+ Images Flashcards
A predecessor activity is one that comes before another activity. A successor activity is one that comes after the activity in question. Figure 4.1 shows a simple predecessor/ successor relationship between Activity A and Activity B.
The most commonly used network diagramming method is the precedence diagramming method (PDM) . PDM uses boxes to represent the project activities and arrows to connect the boxes and show the dependencies. Figure 4.2 shows a simple PDM network diagram of tasks with fi nish - to - start dependencies.
You also need to be aware of the difference between workdays and calendar days. If your workweek is Monday through Friday and you have a four - day task starting on
Thursday, the duration for that task will be six calendar days, because no work will be done on Saturday and Sunday. Figure 4.3 illustrates this situation. The same concept applies to holidays or vacation time.
Most projects use some combination of the estimating techniques explained here. Once you have determined which estimating technique works best for your project, assign a duration estimate to each task, as illustrated in Figure 4.4.
Project communication always involves more than one person. Communication network models are a way to explain the relationship between the number of people engaged in communicating and the actual number of interactions taking place between participants.
For example, if you have fi ve people in a meeting exchanging ideas, there are actually ten lines of communication among all the participants. Figure 5.1 shows a network model showing the lines of communication among the members.
It may be useful to develop a stakeholder engagement plan that describes the key points you need to get across:
- Identify which aspects of the project plan to communicate.
- List any known or probable benefits or concerns from the stakeholder.
- Determine key message to convey to each stakeholder.
Figure 5.2 shows an example of a stakeholder engagement plan using the customer operations scenario for a new product deployment
The project team lead is accountable for either
the people assigned to a particular phase such as development or testing or for the team
members from a specifi c department such as sales, training, IT, or accounting. Figure 5.3 shows a sample project organization chart using the team lead concept
Flowcharting uses diagrams that depict the relationship of various elements in the project. Developing a fl owchart can help you anticipate where and when a problem
may occur. You can build in checkpoints to assess the quality of a particular activity before the next step is started. Data fl ow diagrams (DFDs) are used to help programmers break down a system into its various components, and they ’ re similar to fl owcharts.
Figure 6.1 shows a sample fl owchart and DFD for the process of a customer interacting with a company through a customer service website
With this data in hand, you can create a Pareto diagram, as shown in Figure 9.1. The bars are ordered from left to right based on frequency. The bars depict the defect numbers, and the cumulative percentages are plotted using the circles. By looking at the data in Figure 9.1,
you can see that the most significant problems you want to focus on are A and B. Fixing these two items will resolve more than half the defects.
Control charts A control chart measures and displays the variance of several samples of the same process over time. It is most commonly used in manufacturing. A control chart is based on a mean, an upper control limit, and a lower control limit. The upper control limit is the point beyond which preventing additional defects becomes cost - prohibitive. The lower level is the limit at which the customer or end user will reject the product because of
the defects. The goal is to stay in the middle area (the mean), where the best product for the lowest cost is obtained. Figure 9.2 shows an example of a control chart.
Ishikawa diagram An Ishikawa diagram (named after its developer, Kaoru Ishikawa) is also known as a cause - and - effect diagram , which shows the relationship between the effects of problems and their causes. This diagram depicts every potential cause and subcause of a problem and the effect that each proposed solution will have on the problem. This diagram is also called a fi shbone diagram . Figure 9.3 shows an example
cause - and - effect diagram.
The classic organizational structure is the functional organization , as shown in Figure 1.1. In this structure, the staff is organized along departmental lines, such as IT, marketing, sales, network, public relations, customer support, and legal. Each department is managed
independently with a limited span of control. This organizational type is hierarchical in nature, with each staff member reporting to one supervisor, who in turn reports to one supervisor, and so on up the chain. Figure 1.1 shows a typical functional organization.
Matrix organizations typically are organized along departmental lines, like a functional organization, but resources assigned to a project are accountable to the project manager for all work associated with the project. The project manager is often a peer of the functional
staff managers. The team members working on the project often have two or more supervisors — their functional manager and the project manager(s) they are reporting to.
The process groups are tightly linked. Outputs from one group usually become inputs to another group. The groups may overlap, or you may fi nd you have to repeat a set of
processes within a process group. For example, as you begin executing the work of the project, you may fi nd that changes need to be made to the project plan. So, you may repeat some of the processes found in the Planning process group and then re - perform many of the Executing processes once the changes to the plan are made. This is known as an iterative approach. Figure 2.1 shows the links between the groups.
The last type of organizational structure we ’ ll cover is the project - based organization, which is shown in Figure 1.3. This organizational structure is far less common than the
other two we ’ ve discussed. In this environment, the focus of the organization is projects, rather than functional work units.
Phase closure occurs at the end of each project phase and involves all the steps listed here. You ’ ll obtain acceptance and sign - off at the completion of each phase as well as at the end of the project. The transfer that occurs in phase completion is the offi cial hand - off to
the next phase of the project, not to an operations or maintenance group.
Table 4.1 shows the completed early start and early finish calculations for each of the tasks in the network diagram. Based on the calculations from this completed forward pass, the project is completed on day 20.
You can document an overall communications plan by doing the following:
- Defining who needs information on your project
- Defining the types of information each person or group needs
- Identifying the communications format and method of transmission
- Assigning accountability for delivering the communication
- Determining when the communications will occur and how often
Table 5.1 shows a simple way to display this information
A well - known tool used in project management circles for defi ning and documenting the human resource requirements is a responsibility assignment matrix (RAM) . A RAM is a chart that matches your WBS elements with the required resources. Table 5.2 shows a sample portion of a RAM for an IT development project. It lists the WBS identifi er, the type of resource required, and the number of resources needed for each skill set.
An RACI chart identifi es the task to be performed,
the individual or organization assigned to the task, and what level of responsibility or involvement they have for this task. Their level of involvement or responsibility is
designated by the letters R - A - C - I, which stand for the following:
R = Responsible, the one who performs the work
A = Accountable, the one who is responsible for producing the deliverable or work
package and approves or signs off on the work
C = Consult, someone who has input to the work or decisions
I = Inform, someone who must be informed of the decisions or results
Table 5.3 shows a sample RACI chart.
Table 5.4 shows a sample weighted scoring model using
some of the evaluation criteria shown earlier. The scores are assigned a value of 1 to 5, with 5 being the highest score a vendor can earn. You multiply the weight by the score for each element and then sum the totals to come up with an overall score for each vendor. You would almost always choose the vendor with the highest score using this selection method.
A number of things should happen once the change request is submitted. First, it should be assigned an identifying number for tracking purposes. Then, it should be recorded in the change request log. This log is easy to construct in a spreadsheet fi le. Table 8.1 shows a sample change request log.
Make sure that all the participants have reviewed the project charter and scope statement and have a clear understanding of all the deliverables. Have copies of these
documents available as a reference. The team may go through several iterations of constructing the WBS before it ’ s considered complete. Figure 3.1 is an abbreviated example of a WBS for an application development project.
