Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 13

Software Project Management

Assignment

Task : Solve the exercise questions of chapter 22, 23, 24, 25, and 26 from the book Software Engineering by
Ian Sommerville.

Chapter No 22 | Project Management


Q1. Explain why the intangibility of software systems poses special problems for software project
management.

Answer :
Unlike building a ship or a bridge, software development is not as straightforward. You can't physically see or
touch the software, which makes it difficult for project managers to track its progress. Unlike a physical
structure that you can visually inspect to see how far along it is, software development requires different
methods to measure progress. This can create challenges for software project managers trying to keep track of
how far their project has come.

Q2. Explain why the best programmers do not always make the best software managers. You may find it
helpful to base your answer on the list of management activities.

Answer:
When it comes to managing a team of developers, there are certain skills that are important. These skills include
being able to communicate well, organize tasks effectively, and work well with others. However, just because
someone is a good programmer, it doesn't necessarily mean they will be good at managing people. This is
because programming skills are different from the skills required for management, such as communication and
organization. In fact, some people criticize programmers for not being great communicators. So, being a good
programmer doesn't automatically mean someone will be a good manager.

Q3. Using reported instances of project problems in the literature, list management difficulties and errors
that occurred in these failed programming projects.

Answer:
The Mythical Man Month by Frederick P. Brooks Jr. is a classic book that discusses various management
difficulties and errors that occurred in failed programming projects.
Some of these issues include:

Adding more people to a late project: This might seem like a good idea, but it often makes things worse.
When you add new team members to a project that's already behind schedule, it takes time for them to
understand what's going on. This slows everyone down and can make the project even later.

Underestimating how difficult a project is: Sometimes people don't realize how complicated a project is until
they're already working on it. This can lead to unrealistic deadlines and not enough resources, which can cause
the project to fail.
Poor communication: When team members don't communicate well with each other or with the people who
are interested in the project, things can go wrong. People might misunderstand what they're supposed to do, or
they might not know what's expected of them. This can cause missed deadlines and mistakes.

Not planning properly: When a project isn't planned well, it can be hard to keep track of everything that needs
to be done. This can lead to unexpected changes and delays, which can cause the project to fail.

Not testing enough: Before a project is finished, it needs to be tested to make sure it works the way it's
supposed to. If there isn't enough time or money for testing, the project might be released with problems that
make it fail.

Q4. In addition to the risks shown in Figure 22.1, identify at least six other possible risks that could arise
in software projects.

Answer:
Other possible risks are:
Technology: Communications network saturates before expected transaction limit is reached.
People: Level of skill of available people is lower than expected.
Organizational: Organizational changes mean that the project schedule is accelerated.
Tools: Software tools cannot handle the volume of data available for large systems.
Requirements: New non-functional requirements are introduced that require changes to the system
architecture. Estimation: The difficult of the software is underestimated.

Q5. Fixed-price contracts, where the contractor bids a fixed price to complete a system development, may
be used to move project risk from client to contractor. If anything goes wrong, the contractor has to pay.
Suggest how the use of such contracts may increase the likelihood that product risks will arise.

Answer:
When a contract is signed between a customer and a contractor, it could be either fixed-price or flexible. Fixed-
price contracts can create problems because they limit the options available for the contractor to develop the
product. Since the contractor is paid a fixed amount, they may not be willing to spend extra time or effort on the
project. If any issues arise, the contractor may try to reduce the scope of the project or cut back on testing to
save money. This can result in a product that is not what the customer wanted.

Q6. Explain why keeping all members of a group informed about progress and technical decisions in a
project can improve group cohesiveness.

Answer:
It's important to keep everyone in the group on the same page when working on a project. This means being
open and honest about what's going on, both good and bad, so that everyone can contribute their ideas
effectively. When people feel like they're part of a team and that their opinions matter, they're more motivated
to work hard. So, it's important to communicate regularly and keep everyone in the loop!

Q7. What problems do you think might arise in extreme programming teams where many management
decisions are devolved to the team members?
Answer:
Delegating decision-making authority to a team can be beneficial in terms of motivation. However, it can lead
to two main issues:
 Firstly, the team members may prioritize technical considerations over business objectives while making
decisions. This is because the team members are technically skilled, and it can be challenging for them to
focus on broader business perspectives.

 Secondly, due to the emphasis on rapid progress, management decisions may prioritize short-term goals
instead of long-term objectives. Although this approach aligns with the philosophy of Extreme
Programming (XP), sometimes a more detached and long-term perspective is necessary, which can be
provided by a manager.

It is also worth noting that the team may face difficulties in making decisions that may negatively impact
individual team members. This is because XP teams are typically close-knit and may find it challenging to make
decisions that censure individual team members.

Q8. Write a case study in the style used here to illustrate the importance of communications in a project
team. Assume that some team members work remotely and it is not possible to get the whole team
together at short notice.

Answer:
Hassan, an experienced project manager, faced some challenges when the personal circumstances of two team
members changed. Ahmad needed to work from home most days due to her kids' schedules, while Ed relocated
to another part of the country. To maintain team communication, Hassan implemented various technologies,
including weekly Skype conferences, a project blog, a Twitter account, and bi-monthly face-to-face meetings.
The team members were also encouraged to have more frequent Skype and phone discussions. The idea was to
have a range of communication possibilities and not to rely on a single channel.

Q9. You are asked by your manager to deliver software to a schedule that you know can only be met by
asking your project team to work unpaid overtime. All team members have young children. Discuss
whether you should accept this demand from your manager or whether you should persuade your team
to give their time to the organization rather than to their families. What factors might be significant in
your decision?

Answer:
If my manager asked me to deliver software within a deadline that required my team to work overtime without
additional pay, I would consult with the team before making a decision. I believe that they would not agree to
the terms unless there was a significant benefit involved. I will take into account the reasons behind not working
for unpaid overtime and the project's deadline importance before helping the team reach a decision. I will bring
up the issue with my team and try to negotiate with my manager to find a way to compensate my team and me
for the additional work we have done.

Q10. As a programmer, you are offered promotion to a project management position but you feel that
you can make a more effective contribution in a technical rather than a managerial role. Discuss whether
you should accept the promotion.

After careful consideration, I have come to the decision of declining the recent promotion offer for a project
management position. I have always been dedicated to technical roles which align with my interests and
expertise. I strongly believe that my strengths and passion lie in hands-on programming, and I take pride in the
effective contribution I can make through it. Therefore, I am confident that I can best utilize my skills and
knowledge by continuing to focus on technical roles.
Chapter No 23 | Project Planning
Q1. Under what circumstances might a company justifiably charge a much higher price for a software
system than the software cost estimate plus a reasonable profit margin?

Answer:
Sometimes, companies charge a high price for their services. Here are some reasons why:

1. If a project is risky, the company might charge more to cover potential losses.
2. If a customer needs their project done very quickly, the company might charge more for the extra effort.
3. Sometimes, when a company takes on a project that's not really related to their main business, they might
charge more to make up for the time and resources spent away from their main focus.
4. In some cases, a company might be the only option for a customer, so they might charge more because they
know the customer doesn't have anywhere else to go.

It's important to think about whether it's ethical to charge too much in these situations.

Q2. Explain why the process of project planning is iterative and why a plan must be continually reviewed
during a software project.

Answer:
When you start a new project, there are usually many unknowns and uncertainties. You might not have all the
information you need to plan the project perfectly. As you work on the project and gather more information,
you'll be able to make better plans. It's important to keep updating your plans as you learn more, so that your
plans stay accurate and useful.

Q3. Briefly explain the purpose of each of the sections in a software project plan.

Answer:
When starting a project, it's important to have a clear idea of what you want to achieve and how you're going to
do it. Here are some things to keep in mind:

1. Goals: What do you want to accomplish? Be specific about what you're trying to achieve.

2. Strategies: How are you going to achieve your goals? What methods will you use?

3. Objectives: What are the smaller, measurable steps you need to take to reach your goals? Make sure each
objective has a deadline.

4. Activities: What specific actions will you take to achieve each objective?

5. Resources Allocated: What resources (like time, money, and people) do you need to complete your
activities? How will you get them?

6. Responsibilities and Commitments: Who will be responsible for each task? What commitments do they
need to make to ensure success?
7. Work Breakdown Structures: What are the different tasks involved in your project? Break them down into
smaller, more manageable pieces.

8. Risk Management: What are the potential risks that could prevent you from achieving your goals? How can
you mitigate them?

9. Configuration Management: How will you keep track of changes to your project? How will you make sure
everyone is working on the same version?

10. Quality Assurance: How will you ensure that your work meets the quality standards you've set?

11. Testing Plans: How will you test your work to make sure it's functioning properly?

12. Traceability: How will you keep track of everything, and make sure each part of the project is connected to
the others?

Q4. Cost estimates are inherently risky, irrespective of the estimation technique used. Suggest four ways
in which the risk in a cost estimate can be reduced.

Answer:
To reduce project estimation and development risks:
Seek Diverse Opinions: Gather multiple expert opinions to refine estimates for accuracy.
Prototyping: Build prototypes to uncover potential issues and obtain realistic timeframes.
Reuse Software: Adapt existing software to save time and costs in project development.
Set Fixed Budgets: Establish a project budget and prioritize functionality to stay within financial constraints.
Prioritize Requirements: Focus on essential project elements; avoid unnecessary features to streamline
development.

Q9. Some very large software projects involve writing millions of lines of code. Explain why the effort
estimation models, such as COCOMO, might not work well when applied to very large systems.

Answer:
The effort estimation models such as COCOMO estimate the software size based on the application and
function points, and lines of code. For smaller projects, the estimation based on these factors will be effective.
But in the case of large systems, where there will be a millions of lines of codes, coding is only a small fraction
of the total effort. LOC becomes a minor factor in project estimation. The estimation models may not work well
when there is ambiguity in counting codes. Effort estimation depends on various factors such as requirements,
plans, people, etc. So far very large systems, the effort estimation models such as COCOMO might not work
well.

Q10. Is it ethical for a company to quote a low price for a software contract knowing that the
requirements are ambiguous and that they can charge a high price for subsequent changes requested by
the customer?
In the context of software contracts, it is generally considered unethical for a company to quote a low initial
price when they are aware that the requirements are ambiguous and that they can charge a high price for
subsequent changes.
Chapter No 24 | Quality Management
Q1. Explain why a high-quality software process should lead to high-quality software products. Discuss
possible problems with this system of quality management.

Answer:
The process of making things involves using machines that need to be set up and operated correctly in order to
create good quality products. It's important to manage and improve the way things are made so that there are
fewer mistakes. Making software is a creative process that relies on the skills of individual people. Changes in
technology and the need to release products quickly can sometimes result in products that are not as good as
they could be.

Q2. . Explain how standards may be used to capture organizational wisdom about effective methods of
software development. Suggest four types of knowledge that might be captured in organizational
standards.

Answer:
Standards are like a collection of good practices that have been developed over time by an organization.
Knowledge that might be captured in organizational standards include:
1. Knowledge of specific types of fault that commonly occur in the type of software developed by an
organization. This might be encapsulated in a standard review checklist.
2. Knowledge of the types of system model that have proved useful for software maintenance. This can be
encapsulated in design documentation standards.
3. Knowledge of tool support that has been useful for a range of projects. This can be encapsulated in a standard
for a development environment to be used by all projec ts.
4. Knowledge of the type of information that is useful to include as comments in code. This can be encapsulated
in a code commenting standard.

Q3. Discuss the assessment of software quality according to the quality attributes shown in Figure 24.2.
You should consider each attribute in turn and explain how it might be assessed.
Answer:
Safety Make sure the software is safe to use and meets safety standards.
Security Ensure that the software is secure and doesn't have any vulnerabilities that could be exploited by
hackers.
Reliability Check that the software works consistently and doesn't crash or fail unexpectedly.
Resilience Test the software's ability to recover from failures and stressful situations.
Robustness Make sure the software can handle unexpected situations without crashing or malfunctioning.
Testability Evaluate how easy it is to test the software to ensure it's working properly.
Usability Gather feedback from users and ensure the software is easy to use.
Adaptability Check how easily the software can be modified or extended to meet changing needs.
Modularity Assess the software's structure to make sure it's easy to modify and update.
Efficiency Measure how quickly and well the software performs tasks.
Complexity Analyze the software's code and design to ensure it's not overly complex or difficult to
understand.
Learnability Evaluate how easy it is for users to learn how to use the software.
Portability Test the software to make sure it works well in different environments and can be easily
transferred.
Reusability Ensure that components of the software can be easily reused in different contexts.
Q4. Design an electronic form that may be used to record review comments and which could be used to
electronically mail comments to reviewers.
Answer:
Any form design that includes the following fields is acceptable:
1. Name of person raising review comment
2. Date comment raised
3. Contact phone number or e-mail address
4. The review comment itself
5. Name of comment assessor
6. Date of comment assessment
7. Action taken from comment (Return for clarification, invalid comment, accepted comment)
8. System change proposed
9. Person responsible for change
10. Date change made
11. Date change checked

Q5. Briefly describe possible standards that might be used for:


Control Constructs in C, C#, or Java:
Follow industry coding standards like MISRA-C for C, Microsoft's guidelines for C#, and Oracle's coding
conventions for Java.
University Term Project Reports:
Adhere to a specified academic format (e.g., APA, MLA), include sections like introduction, methodology,
results, and conclusion, and meet submission deadlines.
Making and Approving Program Changes:
Implement a version control system (e.g., Git), follow a change management process with clearly defined stages
(e.g., development, testing, approval), and document changes thoroughly.
Purchasing and Installing a New Computer:
Follow organizational procurement policies, ensure compatibility with existing systems, and have an installation
plan with considerations for data migration and user training.

Q6. Assume you work for an organization that develops database products for individuals and small
businesses. This organization is interested in quantifying its software development. Write a report
suggesting appropriate metrics and suggest how these can be collected.

Answer:
The organization collects metrics to evaluate its software development, specifically for its database products for
microcomputers. The metrics should take into account the software's characteristics, as it is shrink-wrapped and
may run on different system configurations, and is database-based, which requires that the system does not
corrupt the database.
Product metrics include measured faults, database corruption, system failures, transactions processed, and time
to read/write large DB records.
Process metrics include testing configurations, fault reports, fault clearing time, and system regression test
duration.

Q7. Explain why program inspections are an effective technique for discovering errors in a program.
What types of error are unlikely to be discovered through inspections?

Answer:
Program inspections are effective for the following reasons:
1. They can find several faults in one pass without being concerned about interference between program faults.
2. They bring a number of people with different experience of different types of errors. Hence, the team
approach offers greater coverage than any individual can bring.
3. They force the program author to re-examine the program in detail - this often reveals errors or
misunderstandings.
The types of errors that inspections are unlikely to find are specification errors or errors that are based on a
misunderstanding of the application domain (unless there are domain experts in the team).

Q8. Explain why design metrics are, by themselves, an inadequate method of predicting design quality.

Answer:
Goals that are not clearly defined or are too general can negatively affect metrics. This includes situations where
sub-goals are not defined, goals lack relevance to the industry, goal specifications are informal, or criteria for
achieving goals are unspecified.

Metrics can be easily misunderstood without a proper context. For example, applying component-oriented
metrics in an object-oriented environment can lead to inaccurate interpretations.

Metrics often lack validation, which can impact their accuracy and correlation with other metrics. It's important
to ensure that the metric measures what it intends to measure and that it correlates with existing metrics.

Inconsistent interpretation of metrics is a common issue that arises due to a lack of agreement on terms such as
"measurement," "measure," "metric," and "measurable attribute." This inconsistency can confuse software
measurement.

Q9. Explain why it is difficult to validate the relationships between internal product attributes, such as
cyclomatic complexity and external attributes, such as maintainability.

Answer:
Maintaining complex systems can be a difficult task. It's not just about the system's complexity, but also about
other important factors like how the system is documented and the skills of the people who maintain it. These
factors can have a big impact on the maintainability of a system and can even mask the differences in
maintainability caused by its complexity. Although there is some evidence suggesting a relationship between
maintainability and complexity, we need more information before we can say for sure.

Q10. A colleague who is a very good programmer produces software with a low number of defects but
consistently ignores organizational quality standards. How should her managers react to this behavior?

Answer:
If a programmer produces software with a low number of defects but consistently ignores organizational quality
standards, the managers should define quality criteria, commit to enforcing it, ensure adherence to project
requirements, encourage teamwork, perform quality audits, and inspect for defects resulting from compromised
quality. This will help the programmer understand the requirements and enforce the quality standard.

Chapter No 25 | Configuration Management


Q1. Suggest five possible problems that could arise if a company does not develop effective configuration
management policies and processes.

Answer:
The problem that could arise when a company does not develop effective configuration management policies
and processes are as follows:
1. It is not possible to create new versions of software systems effectively as they change. As well as it is not
possible for the developers to keep track of the changes to the software.
2. It is difficult to control the costs and effort involved in making changes to a system.
3. There may be chances to forget the storage place of the software source code for a particular version. In some
cases, wrong version of a system may be delivered to the customers.
4. Configuration management is seen as a part of a more general quality management process which results in
ineffective quality management process.
5. If some one is leaving the company, then it is very difficult to protect investments in software, and to
reproduce a build with the correct component or continue development.

Q2. What are the benefits of using a change request form as the central document in the change
management process?

Answer:

Using a Change Request Form has multiple benefits.


It allows project managers to assess the impact of changes on the project's timeline, budget, and overall scope,
and make informed decisions on whether to implement them immediately or defer them. It also promotes
transparency and accountability among all stakeholders, fostering trust and confidence. Additionally, assessing
and documenting proposed changes helps with identifying potential risks and evaluating whether the benefits of
implementing the change outweigh the associated risks, minimizing negative impacts on the project's success.

Q3. Describe six essential features that should be included in a tool to support change management
processes.

Answer:
1. Change request form definition.
2. Change request validation.
3. Workflow definition – showing the flow of the change request form.
4. Change costing support.
5. Change request traceability – ie maintaining information about the changes made to the software to
implement the change request.
6. Change notification and reminders – notification to people involved of work done and reminders to team
members who have work to do.

Q4. Explain why it is essential that every version of a component should be uniquely identified. Comment
on the problems of using a version identification scheme that is simply based on version numbers.

Answer:
Unique identification of each component version is essential to avoid confusion, enable traceability, and
facilitate proper version control. Using only version numbers can lead to ambiguity, as different components
may share the same version number, making it challenging to track changes accurately and causing potential
conflicts in the development and deployment processes.
Q5. Imagine a situation where two developers are simultaneously modifying three different software
components. What difficulties might arise when they try to merge the changes that they have made?

Answer:
There is the usual problem where developers each make changes to the same component and these changes are,
in some way, incompatible. However, where several components are being changed at the same time, the
problems are exacerbated because there may be dependencies between the components that are affected by the
changes.
For example, say developer A checks out components X and Y and decides to implement a change by changing
Y, which depends on a particular feature of X. Developer A checks X and Y back in with no changes recorded
as being made to X. Developer B also is working on X and Y and changes both X and Y. However, the changes
made to X mean that the assumptions made by Developer A no longer hold. However, incompatibility is not
detected as there has only been a single change made to component X. With more than 2 components, the
problem becomes even worse because of the chains of dependencies that can be introduced. These can be very
difficult or impossible to detect automatically.

Q6. Software is increasingly being developed by teams where the team members are working at different
locations. Suggest features in a version management system that may be required to support this
distributed software development.

Answer:
In distributed software development, a version management system must facilitate seamless collaboration
among team members working across different locations.
Essential features include robust branching and merging capabilities for parallel development, granular access
controls to ensure secure collaboration, efficient conflict resolution mechanisms to handle simultaneous
changes, and the ability to work offline, allowing team members in different time zones to contribute effectively
and synchronize their work upon reconnection.

Q7. Describe the difficulties that may arise when building a system from its components. What particular
problems might occur when a system is built on a host computer for some target machine?

Answer:
1. Have all components been included?
2. Is the right version of all components been included?
3. Are all configuration/data files included?
4. Is the right version of the system building tools used?
5. Are there any problems with full path name references?

Q8. With reference to system building, explain why you may sometimes have to maintain obsolete
computers on which large software systems were developed.

Answer:
Obsolete computers may have to be maintained if the software used to build the system (compiler, linker, etc.)
is not available for newer hardware. This situation can arise of the compiler vendor has gone out of business and
no-one else is supporting their system. It may not be possible to use a compiler on a newer system as the code
produced may be different. It can also arise when programs are developed in a programming language that is no
longer used – it may be cheaper to maintain the obsolete hardware to run the compiler than to buy a new
compiler for occasional use.
Q9. A common problem with system building occurs when physical file names are incorporated in system
code and the file structure implied in these names differs from that of the target machine. Write a set of
programmer’s guidelines that helps avoid this and any other systembuilding problems that you can think
of.

Answer:
1. Avoid hardcoding file names: Use variables or configuration files for adaptability.
2. Utilize relative paths: Opt for relative over absolute paths for portability.
3. Configuration-based settings: Store configurations separately for easy adjustments.
4. Standardized naming conventions: Adopt platform-independent naming for consistency.
5. Documentation and version control: Maintain thorough documentation and use version control for systematic
updates.

Q10. Describe five factors that should be taken into account by engineers during the process of building a
release of a large software system.

Answer:
1. Have all components been included in the build instructions
2. Has the right version of each component been specified
3. Are all data files available;
4. Are all data files properly referenced
5. Are the correct versions of the compiler or other tools available and specified

Chapter No 26 | Process Improvement


Q1. What are the important differences between the agile approach and the process maturity approach
to software process improvement?

Answer:
The fundamental difference in these approaches is that the agile approach is people-centric and the process
maturity approach is process centric.
In the agile approach, practices are introduced that are geared to supporting communication between people,
making it easier for them to make changes to the software and minimizing the time that they need to spend
doing things apart from software production (e.g. documentation).
The process maturity approach is based on defined processes that incorporate good practice and in ensuring that
these processes are followed by all of the teams in an organization. They assume that by defining process and
good practice, all engineers involved in development can perform in a comparable way. That is, they do not
focus on the capabilities of the individual engineers but rather on being able to maintain consistent practice even
although the team changes.

Q2. Under what circumstances is product quality likely to be determined by the quality of the
development team? Give examples of the types of software product that are particularly dependent on
individual talent and ability.

Answer:
Product quality is significantly influenced by the competence of the development team, particularly in scenarios
where individual talent matters. This is evident in the SDLC, ensuring consistency with user needs. The team's
expertise is crucial for good functionality, reliability, consistency, durability, and performance. Examples of
software highly dependent on individual talent include generic products like word processors and customized
products like air traffic control systems, where tailored solutions demand specialized skills.

Q3. Suggest three specialized software tools that might be developed to support a process improvement
program in an organization.

Answer:
1. Gap Analysis:
 Examines and assesses performance.
 Identifies the difference between current and desired state.
 Helps businesses to address performance gaps.

2. Root Cause Analysis:


 Helps understand the underlying causal factors.
 Identifies the root causes of problems and pain points.
 Enables organizations to address problems at their source.

3. Hoshin Kanri:
 A strategic planning method for organizations.
 Ensures everyone is driving towards the same goals.
 Involves a bottom-up approach to change deployment.

Q4. Assume that the goal of process improvement in an organization is to increase the number of
reusable components that are produced during development. Suggest three questions in the GQM
paradigm that this might lead to.

Answer:
Goal: Increase the number of reusable components
Q1: How many components are currently reused in our development?
Q2: Are there activities in our ‘standard’ processes that are geared to discovering reusable components? How
much time/effort do engineers expend looking for reusable components.
Q3: What percentage of developed components are candidates for reuse?

Q5. Describe three types of software process metric that may be collected as part of a process
improvement process. Give one example of each type of metric.

Answer:
1. Elapsed time.
How long it takes to do something. Many possible examples e.g. time taken to carry out design review.
2. Resource utilisation.
The amount of resources used. E.g. the effort required to test a module.
3. Events that occur.
E. g. The number of defects discovered after a system has been delivered.

Q7. Give two advantages and two disadvantages of the approach to process assessment and improvement
that is embodied in the process improvement frameworks such as the CMMI.

Answer:
Advantages of process improvement frameworks
1. Provides a means of measuring the state of a process and a structured approach to introducing process
improvements.
2. Useful as a way of building on the experience of others in process improvement.
Disadvantages of process improvement frameworks
1. Like any measurement system, there is a tendency to introduce improvements to improve the measured rating
rather than concentrate on improvements that meet real business goals.
2. Expensive and bureaucratic to operate. Not suitable for agile approaches.

Q8. Under what circumstances would you recommend the use of the staged representation of the CMMI?

Answer:
The staged version of the CMMI could be used when an organization has experience of and has been assessed
using the earlier, staged Capability Maturity Model. The staged CMMI is compatible with this and its use would
be a means of continuing improvement according the the CMM approach. You might also use it in
organizations that are very immature and, for the earliest activities at least, would like a package of
improvements to introduce.

Q9. What are the advantages and disadvantages of using a process maturity model that focuses on goals
to be achieved, rather than good practices to be introduced?

Answer:
Advantages
This model is a technique for the achievement of a goal through consistent and well-planned processes.
Doing things in sequential and detailed processes will protect the output from rework and rejection thus
assuring quality output at the end.

Disadvantage
The downside of this approach is that, it may not be able to meet the timeline provided in conducting a
particular work or processes because of low or unacceptable audit or measure of the processes conducted. If
this happens, it will affect the delivery of the output (product or service) to the target users.

Q10. Do you think that process improvement programs, which involve measuring the work of people in
the process and introducing changes into that process, can be inherently dehumanizing? What resistance
to a process improvement program might arise and why?

Answer:
To improve a company's performance, you need to measure how things are done and find ways to make them
better. This involves a few steps: analyzing the current process, evaluating the outcome, making changes,
reallocating job roles, implementing the changes, communicating the new process, and monitoring the progress.

However, there might be resistance to change due to unfamiliarity, time consumption, or new technology. It is
the responsibility of the management to help the employees adapt to the new process and explain why it's
beneficial for everyone. This way, the employees and the company can thrive together.
__________________________________________________________________________________________

You might also like