Visualizing Project Management Models and frameworks for mastering complex systems 3rd phần 7 potx

262 THE TEN MANAGEMENT ELEMENTS IN DETAIL Data Control A data manager should control contract data and approved baseline artifacts. Typical tools include a project library and a computer- based document management system. Self-Control Self-control operates at the most personal level. This kind of control is infectious. “Setting a good example” includes: •Being on time to work and to meetings. •Demonstrating high personal standards. •Remaining centered in times of stress. • Delivering to all promises. and controlling the pen by: •Authoring straw-man documents. •Proposing agendas. •Recording action items. •Reviewing and signing letters. Management by Objectives Management by Objectives (MBOs) can supplement, or in some cases substitute for, the Project Work Authorizing Agreements (PWAA) in- Table 14.2 Summary of Contract Types Type Application Control Provided Fixed price Reliable prior cost experience Firm technical, cost, and schedule Cost reimbursement Research or development with advancing Flexible objectives technology Cost sharing Seller shares cost in return for use Result ownership of technology Time and material Not possible to estimate the task beforehand Labor and material rates Labor hour Like time and material, but labor only Labor rates Indefinite quantity Establishes price when quantity and schedule Item price are uncertain Letter Limited project start without completed Initial spending rate and negotiations amount cott_c14.qxd 7/5/05 8:20 AM Page 262 PROJECT CONTROL 263 troduced earlier as the planning technique to control work authoriza- tion and release. Conversely, managing with definitive PWAAs can be thought of as MBO in its most effective form. In either approach, the corporate accounting system should provide cost accounting down to the task level in order to measure cost performance against the PWAA/MBO commitment and to provide early, in-process warning of variances and unfavorable trends. In the absence of a WBS/PWAA system, a rigorous MBO system can accomplish many of their control functions. MBO is also a useful supplement to WBS/PWAA at a more detailed and shorter range as- sociated with short time schedules and/or the first and second levels of the organization. Many companies and government organizations have developed comprehensive MBO systems. Among their primary benefits, MBOs align individual contributions with the broadening objectives at each level of the organizational hierarchy, starting with the top strategic objectives. In that environment, project teams can benefit substantially by applying the same MBO structure to align project team goals down to functional unit goals and further to individual team member goals as well. For an MBO system to be effective and self-motivating for the user, objectives need to be documented (typically on a quarterly schedule) and reviewed/revised regularly (usually weekly) and in detail. An effective system is characterized by objectives that are: •Specific, clear, and unambiguous, •Realistic, measurable, and verifiable, •Consistent with available resources, and •Consistent with company policies. The best results are usually obtained by starting at the top lev- els. Every manager and all individual contributors draft their own objectives to fit with the level above while adding more detail and assumptions to represent their specific contributions. Each objec- tive needs to include assumptions, measurement means, and verifi- cation methods. Joint commitments should be negotiated among theparties to arrive at identical objective statements. Team objec- tives are best negotiated with the team leader in a consensus driven session. Embracing Micromanagement Our Management Methods Survey reveals that micromanagement is universally scorned in all industries, workplaces, and in the press. Micromanagement is widely perceived as an incompetent manager “Set a good example. It will please some people and amaze the rest.” Mark Twain A loosely managed MBO sys- tem is worse than none at all. cott_c14.qxd 7/5/05 8:20 AM Page 263 264 THE TEN MANAGEMENT ELEMENTS IN DETAIL nit-picking the work of a qualified subordinate who knows better. We characterize this scenario as “Nit Management” in that the per- ceived content and the consequences of the content to the project outcome appear miniscule. One of the authors was on a senior manager’s staff when our new boss arrived. The new boss spent two hours describing how to fill out a time card (pencil, not ink; block letters; each letter in the box, not overlapping the edges; etc.). Since none of us had to fill out time cards, nor had we for 20 years, this was an exercise in Nit Man- agement at its finest. However, “the devil is in the details,” “no change is a small change,” and, “people must not mess up” suggest that supervisory attention to detail may often be appropriate. TQM, Six Sigma, CMMI, and the learning organization are all about honing detailed processes to where results are efficient and repeatable with no “messing up.” Intel has a philosophy of “getting it exactly right and replicating exactly.” These are all examples of “positive” microman- agement in action. The appropriate use of micromanagement is when the risk of failure is so high that you will not be satisfied until you are person- ally confidant that it has been managed properly. Experienced air- line pilots go through a detailed checklist each time they are preparing to take off. Hopefully, this is not because they cannot re- member how to fly the airplane, but rather the catastrophic conse- quences of omitting a step. A few years ago one airline reexamined their preflight procedures with a competitive goal to shorten the turnaround time from 45 minutes to 20 minutes. They deleted as unnecessary the step that required the pilot to initial the me- chanic’s worksheet showing the amount of fuel loaded onto the plane. This saved about five minutes in turnaround. The FAA re- ported that in the first two years after the change was made the air- line had 12 flights that had taken off without enough fuel to reach their destination, forcing an emergency “unscheduled” landing at an intermediate airport. Maybe the pilot’s micromanagement of the fuel log wasn’t such a bad thing after all. The following blunder cost the European Commission (EC) over $100 million: A lawyer’s failure to operate a fax machine correctly has been blamed for the EC losing a multimillion-euro court case. The European Court of First Instance ruled in favor of five German banks that had been fined a total of $100 million by the EC. In 2001, they had been found guilty of running a cartel to fix for- eign currency rates ahead of the introduction of the euro. The com- cott_c14.qxd 7/5/05 8:20 AM Page 264 PROJECT CONTROL 265 Configuration management is often a key project success factor, making it one of the most important proactive con- trol processes. panies—Dresdner Bank, Commerzbank, HVB, Beursche Verkehrs- bank, and Vereignsund Westbank—appealed this decision, and their case was concluded yesterday. According to the Financial Times, the European Court of First Instance overturned the fine because an EC lawyer who attempted to fax a 100-page document outlining the Commission’s case had acci- dentally placed it face upward in the fax machine. This error meant the court received 100 blank pages, and the ac- tual document was not received in time. With no other legal argu- ment from the EC, the court had to rule in favor of the five banks. With something this significant do you think micromanagement might have been appropriate? There are many process steps that should have been taken. Why didn’t they make a phone call to con- firm that the fax was received properly? With something this impor- tant, why wasn’t there a second person there to assist and verify that the fax was being sent properly? The flawed process was the signifi- cance, not just putting the paper in upside down in the fax machine (which many of us have done at one time or another). Another example is the multihundred-million-dollar satellite that fell off the test stand because tie-down bolts were missing. The issue is not that the bolts were missing, but rather that no one checked be- fore moving the satellite. This is another instance where appropriate micromanagement would have saved the project. Defining and following a correct process is vital to any project. Verifying that critical steps have been taken is equally important. CONFIGURATION MANAGEMENT AND CHANGE CONTROL Change happens. Requirements are almost always added, deleted, or changed. There are two ways to deal with these changes: 1. Prohibit them—not client responsive. 2. Control them proactively—client responsive. Configuration management (Figure 14.3) is the process for con- trolling the evolving project baselines in a climate of change. Its purposes are to: •Keep evolving baselines up to date and communicated. •Keep the business, budget, and technical baselines congruent (Chapter 7, Table 7.1). If the task at hand is critically important, then micromanage- ment is a technique worth considering. cott_c14.qxd 7/5/05 8:20 AM Page 265 266 THE TEN MANAGEMENT ELEMENTS IN DETAIL •Ensure that the evolving solutions are consistent with the base- lines. •Manage the physical and functional characteristics of the solu- tion and its entities. Configuration management recognizes the inevitability of changes in the business case, funding, technical requirements, and configura- tion of hardware, software, and operations. It provides the techniques and tools to identify, control, and communicate those changes. It ac- counts for changes as they reverberate through the baselines, impact- ing technical performance, budgets, and schedules. Each time the project successfully passes a decision gate—a point of consensus be- tween seller and buyer—the approved baselines that result are for- mally managed and subject to change management. Common project management practice and industry standards focus on technical baseline management, just one critical aspect of configuration management and system integrity. As defined in the margin note, system integrity encompasses the business and budget aspects. System Integrity: the congruency of the business, budget, and techni- cal baselines. A developing system has integrity when its baselines are in agreement or congruent, which results from establishing a balance among the three aspects (business, budget, and technical) at the out- set of the project and maintaining that balance as changes occur to any baseline. The business, budget, and technical baselines in Table 7.1 are so interdependent that project success depends on keeping them in lock step. In this context, integrity exists only when the: Figure 14.3 Configuration management. PMBOK ® Guide The PMBOK ® Guide Sec 4.3.2.2 Project Management Information System covers configuration management and change control within the Project Integration Management. Change control is intended to manage changes—not to pre- vent them. cott_c14.qxd 7/5/05 8:20 AM Page 266 PROJECT CONTROL 267 PMBOK ® Guide The PMBOK ® Guide Sec 4.6 Integrated Change Control identifies three configuration management activities: 1. Configuration Identification. 2. Configuration Status Accounting. 3. Configuration Verification and Auditing. •Technical baseline is managed to satisfy the business baseline (strategic and tactical objectives), and •Budget baseline is structured to allocate resources as needed to accomplish both the technical and business objectives. If congruence does not exist, it means that one or more of the triple constraints will not be satisfied and the project may be deemed a failure. Configuration management is based on controlling artifacts that range from oral statements to physical objects. The simplest forms of written artifacts are dated and signed handwritten notes or white- board representations (also dated and signed). More common exam- ples are version-controlled electronic and paper specifications. Artifacts include hardware and software products with version iden- tification and certifications attesting to their “configuration.” By definition baselines are under change control. Baselines ap- pear at the top of the architecture and then descend, consistent with the solution decomposition, to the detailed parts, code, and processes used to produce the solution. The project management challenge is parallel elaboration of the many baselines such that they are: •Consistent with, and responsive to, their parent baselines, and •Congruent with their peer baselines. Business/Mission Baselines The project cycle discussion in Chapter 7 explained the concept of the business baseline and how it represents the business approach. In considering the configuration management of the business base- line, the following artifacts may require configuration management: Contract.Memorandum of Agreement. Business case. Schedule. Marketing plan. Schedule contingency. Mission case. Milestones. Project charter. Subcontracts. While it’s commonplace to control these project-level artifacts, it should also be recognized that candidates exist at every level of ar- chitecture decomposition and for every deliverable entity of the project. Hence, parent-child traceability is required to ensure proper flowdown, baseline integrity, and change evaluation at every level of the solution architecture. The key for all project teams is to establish sound and achiev- able initial baselines and then to keep them congruent as the inevitable changes occur dur- ing project execution. cott_c14.qxd 7/5/05 8:20 AM Page 267 268 THE TEN MANAGEMENT ELEMENTS IN DETAIL Requirements definition. Concept definition. Architecture definition. Val idation plan. Deployment plan. Concept specification. Ver i f i c a t ion plan. Ver i f i c a t ion procedures. Design-to specification. Build-to documentation. Code-to documentation. Logistics support plan. Operations plan. Maintenance plan. Deactivation plan. Other necessary procedures. Budget Baseline The budget baseline addresses the required resources—obtaining and deploying them as needed to execute the project. It must be consistent with, and supportive of, both the business and technical baselines. Like the business baseline, it too must exist at every level of decomposition and must be responsive to parent and peer baselines. In considering the configuration management of the budget base- line, the following artifacts may require configuration management: Funding schedule. Budgets. Funding availability. Burn rate. Funding contingency. Skill mix. Technical Baseline The technical baseline addresses the evolution and elaboration of the technical solution at all levels of architecture decomposition. The technical baseline is responsive to the business baseline and tends to drive the budget baseline, since that is where most of the resources are consumed. While it is common to manage the technical baseline reasonably well at all levels of decomposition, it is not universal to flow down the associated business and budget baselines to all ele- ments of the solution architecture. In considering the configuration management of the technical baselines,thefollowingartifacts mayrequire disciplinedmanagement: The major goal of a configuration management process, as dia- grammed in Figure 14.4, is to ensure that approved baselines and changes to those baselines are in the best interest of the project. Effective configuration man- agement—an ounce of prevention. INCOSE INCOSE Handbook Sec 5.9 Configuration Management Process and Sec 6.3 Baseline Management provide addi- tional information on manage- ment of baselines. cott_c14.qxd 7/5/05 8:20 AM Page 268 PROJECT CONTROL 269 Change Control A vital element of configuration management provides the means to evaluate and approve changes to the baselines. The change control process can be as simple as a phone call between two programmers with a follow-up e-mail (part of the project documentation) or structured as a Change Control Board (CCB). An ad hoc meeting of the impacted stakeholders with documented minutes lies some- where between. In any case, there needs to be an agreed to process that ensures: • That all impacted parties agree to the process. • That change agreements are documented and communicated. •Compliance. It may be impractical to have a single control board for a large complex project, as it could easily become a bottleneck on the proj- ect’s critical path. The practical solution is to have a layered control board aligned with the project’s architecture. The board at each level should have the appropriate stakeholders, including a systems engineer to represent the overall and customer/user perspective. In their chapter on managing configurations in The Wiley Guide to Managing Projects, Callium Kidd and Thomas Burgess trace the motivation for industry practices and related standards, such as EIA 649 and ISO 10007, to project failures and serious deficiencies. The Figure 14.4 Key elements of configuration management. Configuration Management Process Baseline Approval Create baselines Chang e Control Evaluate & approve changes Baseline Management Status & verify Communicate Histor y & im p act Business, Budget, Technical Baseline Compliance Audit Augustine’s Law—No change is a small change—drives the need for change control. Adjust your process to your project’s size, risk, complexity, and your company/customer guidelines. cott_c14.qxd 7/5/05 8:20 AM Page 269 270 THE TEN MANAGEMENT ELEMENTS IN DETAIL authors acknowledge that, while change controls are widely recog- nized as the best way to stay out of trouble, the appropriate level of rigor is controversial. “There needs to be a documented process for change, through which all changes must progress. The processing of changes through a single change board activity is where most organi- zations see unnecessary bureaucracy in the configuration manage- ment process. For this reason, it is important that clear rules exist whereby change classifications can help streamline the approval/im- plementation process, and changes that are considered minor, or low impact changes, can be directed to those empowered to do so.” 6 The change process usually begins with a change request that documents the change including the technical, budget, and schedule impact. The request precipitates a CCB review (Figure 14.5). The participants include the managers of each affected organization. The project manager chairs the CCB and is responsible for ensuring that: •The decision is informed and objective. • Each change is logged for traceability to the work package level of the WBS. •All affected parties are notified of baseline changes. •Upper management and the customer are officially informed of all baseline changes. • Changes requiring customer approval are forwarded to the cus- tomer change board. The CCB Agenda should include the following issues, which must be thoroughly understood for informed decision making: •The details of the change and the need for it. •The impact of the change on the performance, design, cost, schedule, support equipment, spares, contract, customer, and project team. •The impact of making the change versus not making the change. •Effectivity (e.g., date, versions, and specific units affected). Figure 14.5 The change control board. Usually the impact on people is the trickiest to assess objectively. For this reason, the customer impact and customer position are two different issues. PMBOK ® Guide The PMBOK ® Guide Sec 4.6 Integrated Change Control dis- cusses the role of the change control board as part of Proj- ect Integration Management. cott_c14.qxd 7/5/05 8:20 AM Page 270 PROJECT CONTROL 271 •Documentation affected by the change. • Customer position (i.e., Is the customer supportive of the change?) The project manager needs to factor the customer’s situation into the decision process. Likewise, secondary impacts on the proj- ect team need to be accounted for in schedules. For example, the disruption resulting from redesigns are often underestimated. Con- versely, a substitution or alternative approach could eliminate a source of conflict or risk. Affected work authorizations must be revised to effect a change. Recognizing that a large project requires many PWAAs, rapid action is required to avoid having people working to an obsolete baseline. The opening case of this chapter presented an example of a major failure caused by a poorly implemented change. Use your most ef- fective communication method to notify all affected parties that a change is forthcoming. QUALITY CONTROLS AND TECHNIQUES We def ine quality as conformance to the project’s requirements. Quality is ultimately judged by the customer and end users, not by the project manager or other provider personnel. In this case, the cus- tomer may be any person or organization in the complete provider- customer chain extending from those internal to the project to the in- tended user. It is the final user that determines product or service quality, that is, fitness for use. That viewpoint encompasses ease of learning, usability, serviceability, reliability, durability, and documentation effectiveness. Traditional Quality Assurance The traditional approach to controlling quality (Figure 14.6) fo- cuses on the results of manufacturing operations where quality is most visible. For example, product quality assurance consists of an organization that screens the product (perhaps at several points in the manufacturing process) for adherence to its specifications (Figure 14.7). Suspect material is dispositioned as use-as-is, re- work, or scrap—whichever is appropriate. Eventually, most design or process defects are recognized and corrected by the change con- trol and corrective action process. INCOSE INCOSE Handbook Sec 7.6 Quality Management Process provides additional informa- PMBOK ® Guide The PMBOK ® Guide Ch 8 Proj- ect Quality Management describes three processes: 1. Quality Planning. 2. Quality Assurance. 3. Quality Control. A quality challenge is to develop specifications that will produce products that satisfy the customers’ expectations. cott_c14.qxd 7/5/05 8:20 AM Page 271 [...]... MANAGEMENT INCOSE INCOSE Handbook Sec 5.5 Monitoring/Assessment Process identifies that taking the pulse of actual performance against planned is its main purpose Glance Management encompasses management- by-walking-around (MBWA) and other informal techniques used for follow-up and daily awareness by an appropriate project member, particularly the project manager, chief systems engineer, and subject-matter... TEN MANAGEMENT ELEMENTS IN DETAIL Project visibility includes the facilitation of information gathering and dissemination techniques such as: Meetings Reports Tiger Teams Glance Management Project Information Center Top Ten Problem List These techniques are driven by the timing, need, and geographic location of the required data They change as the project progresses through the project cycle GLANCE MANAGEMENT. .. notices and selected correspondence, the observer can 283 PROJECT VISIBILITY ASSEMBLY A TOP 10 ASSEMBLY C ASSEMBLY E SUBCONTRACTOR ASSEMBLY WBS ORK NETW ASSEMBLY B ASSEMBLY D SOFTWARE ASSOCIATE MASTER SCHEDULE TEST Figure 15.2 A dedicated Short Cycle Room quickly scan for pertinent new information The Project Information Center is an ideal location for all hands and project manager ’s reviews On small projects,... to be over-informed rather than under-informed, when carried to the extreme extraneous information causes overload and missed details Be selective A visibility system can incorporate many techniques and tools You need to determine the timing, critical need, and geographic location of the required information before designing and implementing the system you will use These factors, and therefore the techniques,... current project situation is only meaningful from the perspective of where you need to be in order to reach your destination Planning and status are inextricably linked PMBOK ® Guide This chapter is consistent with the PMBOK ® Guide Ch 10 Project Communications Management and Ch 11 Project Risk Management INCOSE This chapter is consistent with INCOSE Handbook Sec 6.3 Audits and Reviews, and Technical Performance... performance of critical metrics—matched to project complexity and risk • Compares baseline plan to current forecast and actual to plan • Evaluates the deterioration rate if no corrective action were to be taken • Tailors information to the needs of the team members interpreting it Status should be continuously known by task managers and by all levels of project management Others who can affect project. .. subcontractors, and vendors, should provide status as to their critical obligations Brief monthly status reports for distribution to executive management and functional support managers are a necessary communication technique for the project manager and the project team Like many major corporations, Microsoft uses e-mail to distribute and comment on the monthly project status reports Bill Gates and other... is required of management? All-Hands Meetings All-hands meetings involve a larger group—usually the entire project team Attendance by key personnel is mandatory These meetings are typically convened to announce a major development such as a new contract, a technical breakthrough, or the need for extra effort They offer an excellent opportunity for team building PROJECT VISIBILITY 2 87 One-on-One Meetings... The benefits include: • Overall view of the project • Forum for organizational interaction to resolve project issues Headcount variance is often the earliest indicator of more serious problems 288 THE TEN MANAGEMENT ELEMENTS IN DETAIL • Insight for support managers into project needs • Visibility for all key participants into top project issues, concerns, and problems It is often beneficial to hold... what weekend effort can substantially shorten the critical path Executive Management Review The executive management review is to provide upper management visibility into the status of the project It usually consists of a presentation by the project s management on the overall health of the project The format emphasizes accomplishments, particularly regarding contract requirements, and the efficient . Guide to Managing Projects, Callium Kidd and Thomas Burgess trace the motivation for industry practices and related standards, such as EIA 649 and ISO 100 07, to project failures and serious deficiencies expectations. cott_c14.qxd 7/ 5/05 8:20 AM Page 271 272 THE TEN MANAGEMENT ELEMENTS IN DETAIL A sensible and enduring standard for all industries is illustrated in Figure 14 .7. Current ISO quality standards are. X Bracing for a fall X cott_c14.qxd 7/ 5/05 8:20 AM Page 277 278 15 PROJECT VISIBILITY PMBOK ® Guide This chapter is consistent with the PMBOK ® Guide Ch 4 Proj- ect Integration Management and Ch 10 Project