D. A project can be declared complete because its deliverables have been created, or because the success and completion criteria have been met. A project can also be canceled , or the resources just wind up being depleted requiring cancellation. For more information, see Chapter 10.
B, D, E, G, I. You can remember the old poison antidote, syrup of IPECaC (leaving out the a), to assist you with this. Initiation, Planning, Executing, Controlling, and Closing are the five distinct project management process groups . For more information, please see Chapter 1.
A, C, D, E. By not providing adequate requirements formulation, you might have a rough feel for what deliverables youre providing, but you certainly couldnt absolutely pinpoint them. You wont be able to tell when the projects complete or when its successful, and as a result, the scope might enlarge without your being aware of it. Youll probably be able to tell who the customer is. For more information, please see Chapter 3.
C. Signing the project charter authorizes the project work to go forward. For more information, please see Chapter 2.
A, B, C. When the projects costs exceeds its budget, you have to go to the sponsor and get input on what to do next . When the elapsed time taken for one or more tasks far outreaches your initial time estimates or you find that project activity is insurmountable, its time to visit with the stakeholders and project sponsor to see if you need an extension, not to kill the project. If the sponsor loses interest, its time to talk with the sponsor, not necessarily to pull the plug on the project. For more information, see Chapter 8.
B. The sponsor is the one who must sign off on completion of the project, whether successful or unsuccessful . Just as the sponsor is authorized to expend resources to bring forth the projects deliverables, so the sponsor must also close down the project and thus release the resources. For more information, see Chapter 10.
B. The project scope document details the various components that will go into the project to make it happen. The project scope document includes things like the enumeration of the deliverables, the end product thats expected, the risks associated with the project, the budget and any spare funds that may be available to augment the budget, rules and regulations that may impact the project, and so on. For more information, please see Chapters 3 and 6.
A. A top down estimate is one in which youre allocated money in which to complete a project. Because of this youll have to rely on estimates and assumptions in order to apportion the money in each area in which you require it. For more information, see Chapter 5.
B. One of the uses for a milestone is to signal that youve completed one of the deliverables that are to be obtained from the project. For more information, please see Chapter 4.
C. The outcome of your WBS will be the projects deliverables! For more information, see Chapter 7.
A. A more formal approach to the sign-off of the deliverables is a project phase called acceptance testing, where users actually test out the new software to make sure it works correctly and that it does what they need it to do. For more information, please see Chapter 2.
A, C. Anytime theres a significant expansion or modification to the project, the project charter must be modified and the project sponsor must sign off anew on it. For more information, please see Chapter 7.
C. The projects scope document should be of most interest to the new project manager. First, if the project scope doesnt match the concept document and charter, the project manager has a problem. Second, the scope denotes the amount of work involved in the project and, if inaccurate, may result in project overruns both in budget and resource terms as well as schedule. For more information, please see Chapter 3.
A. In an ideal project management world, the IT project manager isnt any different than the project manager thats building a bridge, sinking an oil well, or mapping the Amazon. Wonderful communications skills are the biggest asset any project manager can have. In most IT environments, youll have experts in the various areas that you need for the project. For more information, please see Chapter 1.
B. The project sponsor signs the project charter. For more information, please see Chapter 2.
D. You go through a full-bodied risk assessment process while youre in the Planning phase of the project. You define risks associated with each requirement, try to quantify their impact on the requirement, and prepare a response for each risk. You control risks as they appear when youre in the Controlling phase of your project. For more information, please see Chapter 6 and 8.
D. After the sponsor has formally signed the project plan, youve finished the Planning stage and now move into Executing. For more information, see Chapter 7.
E. While its good to boil the requirements down to separate project steps, thats not always possible. However, you should always strive to word the requirements in such a way that you can assess their success and completeness by some metric. Sponsors and customers dont need to sign off on individual requirements. For more information, please see Chapter 4.
C, E. You should think about including both the success criteria and the completion criteria in your project scope document. Success criteria are the things that youd expect to occur in order to be able to declare the project a success. Completion criteria are the items that must be accomplished to complete the project. For more information, please see Chapter 4.
A, D, E. The amount of time and money a change will require are outcomes of a change control process, not inputs to the process. For more information, please see Chapter 9.
D. The bottom up cost estimating method is recommended for most IT projects that do not result in a product or service that your company will be reselling . The reason for this is that youre managing the project from a pure whats it gonna cost? methodology, rather than how much can we expect to make per unit? perspective. A bottom up estimate is the most precise because you begin your estimating at the smallest of tasks and work your way up. For more information, see Chapter 5.
A. The best way to avoid scope creep as much as possible (youre never going to totally avoid it) is to make sure the projects requirements have been thoroughly fleshed out before the project starts. For more information, see Chapters 2 and 3.
B. Cost estimates do not make up the project budget; they act as an input to the budget. Cost estimates are provided by the team members who will be performing the task theyre estimating. For more information, see Chapter 5.
A. In order to facilitate management buy in to a given project, one of the options to consider is to allow management to review and approve project deliverables. For more information, please see Chapter 2.
D. The project manager assembles the team members for the project. The project manager may certainly have input from the sponsor, stakeholders, or customers, but it is the project manager who decides what the formation of the team should be. For more information, please see Chapter 1.
B, D. There are some project life cycle methodologies that also use milestones to mark the end of one project phase and the beginning of the next. Generally milestones between phases have exit or entrance criteria. For example, consider a standard system development cycle in which you perform rigorous testing. A milestone for moving from a test phase to a deployment phase could have a list of specific test scenarios that must be successfully completed before the testing phase is complete. This is the exit criterion that must be met before the test phase is considered complete. For more information, see Chapter 4.
E. There is a long list of things that can be considered constraintselements that could potentially lengthen the scope of the project. Corporate priorities, suitable members for the project team, and budget restrictions are a few. For more information, please see Chapter 3.
B. The output of scope definition is the Work Breakdown Structure (WBS). The WBS is a deliverables-oriented hierarchy that defines all of the project work. Each level has more detail than the previous level. For more information see Chapter 3.
A, C. Most projects will utilize a Gantt chartbasically a grouping of task blocks put together to reflect the time that each task is going to take relative to a calendar, along with any precursors or successors the task may have. If you were to take some sticky notes and stick them on a flip chart, writing on each note the task, the date it starts, the date it ends, the duration itll take, along with all precursors and successors, youd essentially have a network diagram. Network diagrams are capable of showing interrelationships between tasks that a Gantt chart cannot. Youll use network diagrams on very large projects, whereas most small- to medium- sized projects will work fine with Gantt charts . For more information, see Chapter 4.
A, B, C. Youre interested in what youll use, wholl do the work, and how much the effort will cost, both in terms of materials and time. For more information, see Chapter 5.
B. Think of the phrase well under way as code in the IT Project+ test that means the project is in the Executing/Controlling phases. In high-level projects that have a lot at stake and are under very high visibility, you could use your negotiation skills with the stakeholders and sponsors to try to slim down some of the requirements so as to bring the project in sooner, using less budget, or with greater quality. For more information, see Chapter 8.
A. The project sponsor has authority to spread the news first. He will give you further information and instructions as to the impact on your team. For more information, see Chapter 8.
B. Youll write your project plan then submit to the stakeholders for their review. After you make the recommended changes, youll then submit it to the sponsor for review. If there are no additional changes the sponsor will sign off on the finalized project plan. For more information, see Chapters 2 and 3.
D. You should run a variance analysis on the proposed deviation from scope. You do this by estimating the amount of time the additional tasks the deviation requires and the additional costs. You then compare this to tasks that youve already planned and more or less fit the tasks involved with the deviation. If you cant find a fit, then the tasks represent additions to the scope. You run the variances to see how far over you would be if the new work was added in, and you then have a good feel for how far out of scope the deviation will take you. For more information, see Chapter 9.
C. Variance analysis consists of measuring the predicted cost of resource time, dollar expenditures, and elapsed duration of activities, then comparing these to the actual values. For more information, see Chapter 9.
B, D. A milestone consists of a description, entry criteria, and exit criteria. These criteria detail how you know when youve entered an area of the project that has resulted in a milestone and how to exit this milestone to the next section of the project. For more information, see Chapter 4.
A. There are two indexes associated with earned value analysis: cost performance index (CPI), the budgeted monetary cost of a task versus the actual, and schedule performance index (SPI), the budgeted hours for a task versus actual. For more information, see Chapter 9.
A, B, D. A scope deviation can represent itself in the form of a change in the design of the project, a schedule change (typically a reduction in schedule), or a budget change of some kind. Of these, the design change may have the most far-reaching ramifications in terms of scope alteration. For more information, see Chapter 8.
C. As a project manager, your team members are under your leadership until the projects over. However, in IT projects, youre often working with people from other business organizations (at least for part of the time) to help with the project. Because these people have a regular supervisor whos responsible for keeping track of their performance and time, youre working in what we called a matrixed environment, using matrix management. You track part of their time and performance, and their regular supervisor does the same. Sounds easy, but its very difficult to do in the real world. Politics, personality issues, and other elements get in the way. For more information, see Chapters 1 and 8.
A, C. Youll be directly involved with team members when you find that one of your better workers is, for some reason, not getting her work done as before. Youll also wind up using your people management skills when someone else comes to you to report that another team member isnt working as well as they should be. You have to deal with stakeholders requesting a schedule change before it ever gets to the individual team member level. And you shouldnt pay attention to the gossip mill. For more information, see Chapter 8.
A. The process of examining financial variables to determine where youre at in a project is called earned value analysis. For more information, see Chapter 9.
C, D. When a team loses its focus, it also loses its sharpness and the project begins to go in different directions. Likewise, when teams split out into special interest groups or cliques, the project suffers as well. In either case, its up to you as project manager to manage these very real people situations. For more information, see Chapter 8.
B. Youll create closure documentation that includes items such as lessons learned and the signoff for the closure. Youll also release the resources of the project. For more information, see Chapter 10.
B. When faced with the possibility of a serious scope deviation, the project manager should determine whether there are alternatives that, while compromising the scope, may not have as much impact as the proposed deviation. For more information, see Chapters 8 and 9.
A, B, D. Time (schedule), budget, and quality maintain a delicate seesaw balance with one another, and it is important that project managers keep a close eye on the three. For more information, please see Chapter 5.
A, B, D. You would release resources that were allocated for the project. That would include hardware, human resources, contractors, software, and other such resources. Vendors, while a resource, are released as they supply the things that youre purchasingtheyre not released at closure time. The customer isnt a resource thats released. For more information, see Chapter 10.
C. A Pareto diagram is used to rank the importance of a problem based on its frequency of occurrence over time. This diagram is based on the Pareto principle, which is more commonly referred to as the 80/20 rule. Applying the principle to quality control, it says that the majority of the project defects are caused by a small set of problems. A Pareto diagram helps to isolate what the major problems are, so that you can take action that will have the greatest impact. A bar graph is used to display problems in decreasing order of occurrence so that priorities for improvement can be established. For more information, see Chapter 9.
A, C, F, H. Well-known in general management and project management circles, the concept of developing a high-quality team involves (a) formingthe process team members go through to become established; (b) storming the struggle for control, power, and influence; (c) normingthe process of the team settling into a routine as the project proceeds; and (d) performing when the team is cohesive and able to produce. For more information, see Chapter 8.
A. A systems development life cycle (SDLCalso sometimes referred to as software development life cycle) most commonly denotes five distinct phases: planning, analysis, design, implementation, and operations and support. These phases loosely align with the Guide to the PMBOK process groups. Its important to understand that IT specialists may have had training in SDLC, but not in Guide to the PMBOK . There is a potential for a difference of opinion between the way that SDLCers think things should be handled versus a PMP. By understanding how the two map to one another, smart project managers can avert unneeded project tension. For more information, see Chapter 1.
B. Decomposition is the process of analyzing the requirements of the project in such a way that you reduce the requirements down to the steps and tasks needed to produce them. For more information, see Chapter 2.