Fluent Essays

Ethical Dilemma: Balancing Speed, Cost, and Quality First, consider the following case study background: In this modern economic era of tight budgets, cutbacks, and shortfalls in both budgets and staffs, most organizations are pressured to do more with less. Customers and executive sponsors push projects to complete earlier and cheaper, with less budget funding, but with the same scope and quality. Rapid Application Development (RAD) and Agile and Extreme development methods are pushed. The problem, as always, is with the balance of the triple constraint (this time, with the added factor of quality). There is also a trade-off between the short-term benefits of quality (and of projects themselves, for that matter), and their long-term strategic benefits to the corporation. These economic and strategic forces often result in executives pressuring PMs to take shortcuts in IT projects. While such shortcuts may seem attractive, they usually have highly adverse consequences to the company in both the short term and the long term. One example, of many, is that poor quality could be publicized and have adverse consequences for the company. These pressures from executives, and the related economic pressures, are project risks, and the risks often manifest themselves as quality issues. Now answer these questions: a) If faced with increasing pressure to get a project done ahead of time, what steps should a project manager take if he feels this will jeopardize project quality? b) Suppose that rather than time, the pressure is to do more with less, that is to accomplish the same scope with staff cuts and budget cuts. Does that change your answer? That is, what steps should a PM take if he feels this will jeopardize project quality? c) In addition to the effects that a rushed project might have on project quality, what kind of short-term and long-term effects might it have on project team members? d) What kind of short-term and long-term effects might it have on the organization or corporation itself? Reading Materials: Chapter 10 from Project Management from Simple to Complex was adapted by The Saylor Foundation under https://resources.saylor.org/wwwresources/archived/site/textbooks/Project\%20Management\%20-\%20From\%20Simple\%20to\%20Complex.pdf Project Quality discussion_1_4_q.docx project_quality.pdf Unformatted Attachment Preview Instructions: - Please Use only the assigned readings for the Discussions. Any other source must be cited Answer the question in your own words. Provide a quote, paraphrase or reference from our textbook or other source. Provide examples that demonstrate your answer and understanding of the concept. Question 1: Project Quality Management Ethical Dilemma: Balancing Speed, Cost, and Quality First, consider the following case study background: In this modern economic era of tight budgets, cutbacks, and shortfalls in both budgets and staffs, most organizations are pressured to do more with less. Customers and executive sponsors push projects to complete earlier and cheaper, with less budget funding, but with the same scope and quality. Rapid Application Development (RAD) and Agile and Extreme development methods are pushed. The problem, as always, is with the balance of the triple constraint (this time, with the added factor of quality). There is also a trade-off between the short-term benefits of quality (and of projects themselves, for that matter), and their long-term strategic benefits to the corporation. These economic and strategic forces often result in executives pressuring PMs to take shortcuts in IT projects. While such shortcuts may seem attractive, they usually have highly adverse consequences to the company in both the short term and the long term. One example, of many, is that poor quality could be publicized and have adverse consequences for the company. These pressures from executives, and the related economic pressures, are project risks, and the risks often manifest themselves as quality issues. Now answer these questions: a) If faced with increasing pressure to get a project done ahead of time, what steps should a project manager take if he feels this will jeopardize project quality? b) Suppose that rather than time, the pressure is to do more with less, that is to accomplish the same scope with staff cuts and budget cuts. Does that change your answer? That is, what steps should a PM take if he feels this will jeopardize project quality? c) In addition to the effects that a rushed project might have on project quality, what kind of shortterm and long-term effects might it have on project team members? d) What kind of short-term and long-term effects might it have on the organization or corporation itself? Reading Materials: Chapter 10 from Project Management from Simple to Complex was adapted by The Saylor Foundation under https://resources.saylor.org/wwwresources/archived/site/textbooks/Project\%20Management\%20\%20From\%20Simple\%20to\%20Complex.pdf Project Quality Question 2. Project Risk Management Ethical Dilemma: Risks of Robustness of Testing First, consider the following case study situation: Risk management often brings up ethical issues for project managers. For instance, software testing can be done in several different ways and with several different levels of rigor and comprehensiveness. Simpler tests may be faster and cheaper and may involve less system downtime, possibly using fewer test cases and fewer test runs. More robust testing may be rather expensive and time consuming, including extensive and rigorous test cases, many test runs, regression testing of previously completed production software, and so forth. The PM often must balance robustness of testing with time and cost. (Recall the multi-way balance of the triple constraint.) Sometimes, it can boil down to a trade-off between acceptable quality and delivering a system on schedule and on budget. Either way it goes, that is a risk. The approach usually depends on both the criticality and the context of the system. Then answer these questions: a) From a risk management and project management point of view, in what situation(s) should a system be more robustly tested? b) In what situation(s) might less testing be acceptable? c) Suppose you were the project manager facing pressure from your customer or executive sponsor to reduce testing time when you believe more robust testing was needed. What approach would you use to try to convince the executive manager to follow your advice? Readings Chapter 11 from Project Management from Simple to Complex was adapted by The Saylor Foundation under https://resources.saylor.org/wwwresources/archived/site/textbooks/Project\%20Management\%20\%20From\%20Simple\%20to\%20Complex.pdf Question 3. Project Execution Management Actual Duration Different from Planned First, consider the following case study situation: You are the PM managing a project in which, during project execution, some tasks actually take longer than planned, some go over the planned budget, and the occasional task takes less time than planned. Whats more, some of each of these changed tasks are on the critical path and some are not. Due to astute monitoring, you, as PM, have noticed these changes from the plan. Now, answer the following questions: a) What would have happened if you had not been monitoring the status of the project? b) Suppose that it is crucial that the project complete on time at all costs (e.g., a Mars mission launch window, which, if delayed, will cause the rocket to miss Mars entirely, and for which there is not another launch window for the next 3 years). However, with such a critical project, suppose that changes in actual performance occurred which greatly affected the duration of the project. What could you do about it? c) Would taking these remedial actions depend on when you detected the changes? That is, do they require knowing in advance that there is going to be a slippage or speed-up of a task, or not? d) What else should you do during project execution if such changes made a large change in project duration if there was nothing you could do to remediate it? e) What else should you do during project execution if such changes made a large change in project duration if you could successfully remediate it? Readings; Chapter 8 from Project Management from Simple to Complex was adapted by The Saylor Foundation under https://resources.saylor.org/wwwresources/archived/site/textbooks/Project\%20Management\%20\%20From\%20Simple\%20to\%20Complex.pdf Question 4. Procurement and Stakeholder Management Around here, we keep half the people ignorant so they arent prejudiced, and half the people prejudiced so they arent ignorant. -- Dr. Jay Shulman, c.1980 First, consider the following case study background: Because people dont like to be the bearer of bad news, and are sometimes afraid that their management may kill the messenger, employees are often very reluctant to bring unwelcome but critically important project status information to their management. (This is sometimes known as the mum effect.) Therefore, it is common that important project status information does not make it to the level of management that can take corrective action to do something about it. In fact, it is typical that the farther up the hierarchy a manager is, the less information he or she will have about the project. Unfortunately, this sometimes means that those who have the authority to change things, are the very people who do not know the necessity of the change and/or who do not have sufficient information to enable an appropriate change. Whistle blowing (see below) is an extreme case of bearing the bad news up the hierarchy. Sadly, whistle blowing can be dangerous to ones own career. Unfortunately, whistle blowing in some organizations is considered illegitimate behavior bordering on insubordination. Even when people blow the whistle, management can ignore it (sometimes known as the deaf effect), essentially saying dont give me bad news that I dont want to hear. All this is counterproductive to projects, whose success depends on sound decisions and timely corrections of deviance from plan. For instance, issues that are not elevated to the proper decision- maker before they mature into full-blown problems, become a risk to the success of the entire project. If the decision-maker is kept in the dark, or refuses to make a decision, or punishes the bearer of bad news, then he or she will no longer be in a position to take timely corrective action to keep the project on track to success. Then consider these informal definitions so that we know were talking about the same thing: • Whistle blowing is reporting someone (usually your own management) for doing something illegal or unethical. (Like intelligent disobedience from the questions on the Project Scope Module, we are well advised to pick our battles wisely. Even the Federal whistle blowing office admits that whistleblowers generally are retaliated against, even though that is illegal.) • Recall that in this context, intelligent disobedience, like civil disobedience, is refusing to go along with something that is unethical (whether its legal or not), while fully realizing that we may be punished or penalized for disobeying, and being willing to take the penalty for the greater cause. As Harry Truman said, if you cant take the heat, stay out of the kitchen. The intelligent part comes from not being belligerent and especially from picking our battles wisely. • Insubordination, on the other hand, is probably less-than-intelligent, since it seems to usually be belligerent, not pick its battles wisely, and not be for a greater cause such as ethics. It usually results in management taking career-threatening actions against the employee. • Finally, theres just garden variety differences of opinion. While it should be obvious that that should always be encouraged -- two heads are better than one, after all -- nevertheless, in some organizations, it actually isnt! Now answer the following questions: a) What type of organizational culture might inhibit whistle blowing? Why? b) What should a project manager do to encourage his project teams willingness to report project problems? c) How can a project manager effectively report project problems to the sponsor, stakeholders, and senior management? What techniques might the PM use? If you have not worked for an organization that had internal auditors, Inspectors General (IGs), or other internal inspectors then skip to Part E, below. If you have worked for such an organization, then answer Part D: d) If you have worked for an organization that had internal auditors, IGs, or inspectors, were they effective? Were they welcome? What, in your experience, was done well and what was done poorly with such internal auditors and inspectors? e) If you have not worked for an organization that had internal auditors, inspectors, or IGs, do you think it would be beneficial, detrimental, or problematic? Why? Readings; Chapter 12 from Project Management from Simple to Complex was adapted by The Saylor Foundation under https://resources.saylor.org/wwwresources/archived/site/textbooks/Project\%20Management\%20\%20From\%20Simple\%20to\%20Complex.pdf Managing Project Quality Quality is obviously critical to a project (and to most other things in life). If the project comes in on time, on budget, meeting specs, but with such low quality that nobody wants to use it, then it is a failure. (I think weve all seen Web sites that must meet that definition. Theyre so hard to navigate, use, or find information that theyre not worth using. Presumably, however, they met specs.) For this reason, many people would add quality as a 4th or 5th element of the triple constraint (cost, schedule, scope, and possibly risk). A few notes about quality First of all, quality - like security - needs to be built in, engineered in from the beginning, in fact. It cannot be slapped on at the end. Some places try that for both quality and security, but it doesnt work. Dont cut corners. If the project is worth doing at all, then its worth doing right, i.e., with quality. If it isnt worth doing right, then we might as well not do it at all. If we dont do it with quality, nobody will be happy and we will damage our own reputation, too. As I mentioned above, quality is critical to a project. If the project comes in on time, on budget, meeting specs, but with such low quality that nobody wants to use it, then it is a failure. I think weve all seen Web sites that must meet that definition. Theyre so hard to navigate, use, or find information that theyre not worth using. Project Quality has a lot to do with requirements. A common definition of Project Quality is, the degree to which a set of inherent characteristics fulfill requirements. However, it goes beyond requirements (which are a project scope issue), and among other things also includes processes as well. Consider again that horrible Web site. While its hard to navigate, use, or find information, it presumably met its stated requirements or they probably wouldnt have gone live with it. Also consider the problems that Toyota has been having recently. While their accelerators didnt fulfill their requirements, the underlying cause was that their processes, previously famous for quality, had gone wrong. Also consider Nordstroms and (in the past) Sears. They are/were famous for their quality of service, which is primarily a process issue not a requirements issue. Finally, quality is a value; hopefully, a key organizational value. So quality goes far beyond requirements. Ford Motor Co. used to say quality is Job One. While we may wonder about automobile manufacturers quality these days, it is a very valid point that quality -- like risk management -- is everybodys business. Nobody can pass the buck. Even delegating quality (and security) to someone else doesnt get us off the hook - Everyone is responsible. Agree on quality up front and early. That is, the customer, stakeholders, developers, and PM must be in agreement on what quality is and how to recognize it, or there will be problems later on. It can be tough to reach an agreement, but its worth the trouble to do so. Quality is like IT security in that it must be designed-in rather than added-on later. Designing an IT system then trying to slap on some security at the end doesnt work well. Neither does trying to slap on some quality to a poorly-designed and -built system later on. Test plans should be built up front based on requirements, scope, and agreed upon quality definitions. Then the testing should occur later on during and after development. The test plans should not be drawn up during or after development, and should never be based on what the software or system at that point includes or does. Rather, test plans should always be based on what the requirements say the system is intended to do and on the agreed upon quality criteria. Bells and whistles are not quality. As we touched on when we covered project scope, it may seem counter-intuitive, but a project should not go beyond its requirements or scope. While it should obviously not deliver less than was agreed upon, it also should not deliver more. One way this commonly comes into play is when developers spend inordinate time working on nice-to-have bells and whistles that arent really part of the scope or requirements. Whats wrong with that is that the resources could have been used to bring the project in on or ahead of schedule and on or below of budget instead of adding unneeded features. The savings could either be returned to the customer as a bonus or a discount, or additional features (scope) that the customer needed could have been negotiated when the savings were found. 2 of 2 ... Purchase answer to see full attachment