QSO 340 Project Three

· Updated on December 11, 2025

QSO 340 Project Three Guidelines and Rubric

Competency
In this project, you will demonstrate your mastery of the following competency:
Analyze and reflect on factors that commonly lead to the success or failure of a project
Scenario
You have reached the end of Release One of the XYZ Business Workflow project, and your team has faced some challenges during the development process.
One software tester and one developer from your team resigned. You found replacements for both of them, but the new developer had to be trained by one of your other team members. This affected the team’s productivity.
Also during one of your status meetings with the client stakeholders, their product owner requested a change in a feature that was almost complete. They were also very resistant to give any additional time for the first release. As a result, you had to add extra hours to your development time.
To accommodate these changes, your team worked extra hours and even some weekends to complete the project. Finally, you managed to deliver the first release according to schedule.
The release goes fairly smoothly, but after a few days, the customer reports that their users are facing some issues with the software. They also have a list of changes and two new features they would like to see in the software before your final rollout in Release Two.
Directions
Analysis and Recommendations
Your executive team has asked you to prepare a report summarizing your analysis of the first release of the XYZ Business Workflow software and including recommendations for how you think Release Two of the project should be planned.
Think about the project charter, the initial project plan you created in Project One, and the challenges the project team has faced so far. What steps did you take to manage these challenges? In retrospect, can you think of some other strategies you could have used during project planning and/or risk mitigation for better results? Specifically, your report should include the following rubric criteria:
Reflect on the project so far and provide your analysis of what went well and what could have been better.
Outline what you think were the successes and failures of the project.
Identify major challenges your team faced in completing this project and describe how you handled them.
List some alternate strategies you could have used during project planning and during risk mitigation for better results.
Based on your experience with Release One, provide some recommendations for managing the second release of the XYZ Business Workflow software, including the methodology, change management, and quality control strategies.
Use information from the scenario, Project One, and Project Two, to make reasonable assumptions as you complete these tasks. Be sure to explain your assumptions.
What to Submit
To complete this project, you must submit the following item:
Project Analysis Recommendations
Write a short paper with your analysis of the first phase of the software development project and your recommendations for the second phase. Your paper should be 750 to 1,250 words in length. Cite any references using APA format.

 

Paper For Above Instructions

Introduction and Assumptions

This report summarizes my analysis of Release One of the XYZ Business Workflow software and outlines recommendations for planning Release Two. I am assuming the following based on Project One and Project Two:

  • The project uses an agile, Scrum-inspired approach with two-week sprints and fixed milestones.

  • The core team consists of a project manager, product owner, three developers, two testers, and a business analyst.

  • The project charter defined a fixed go-live date for Release One with a prioritized but flexible scope.

These assumptions guide my reflection on what went well, what did not, and how to improve outcomes in Release Two.

What Went Well vs. What Could Have Been Better

What Went Well

  1. On-time delivery despite disruption.
    Despite losing a developer and a tester, Release One was delivered on the original schedule. This suggests strong commitment and resilience within the remaining team.

  2. Rapid onboarding of new team members.
    Replacements were hired quickly, and a senior developer stepped in to train the new developer, preventing a prolonged productivity gap.

  3. Customer engagement and feedback.
    Regular status meetings with the client ensured ongoing alignment and produced valuable feedback that will inform Release Two.

  4. Team cohesion under pressure.
    Working extra hours and weekends is not sustainable long term, but it shows that the team remained united around the goal of meeting the release date.

What Could Have Been Better

  1. Insufficient risk planning for staff turnover.
    The loss of a developer and tester significantly reduced velocity. Attrition is a well-known risk in software projects and should have been explicitly addressed in the risk register with mitigation plans such as cross-training and documentation. 3Pillar+1

  2. Weak change control for late feature changes.
    The near-complete feature that was changed late in the cycle created scope creep without schedule relief. A more formal change control process could have documented the impact and supported negotiation for either more time or trade-offs. TrustEd Institute

  3. Quality issues after release.
    Post-release issues and requested changes indicate that testing, user acceptance, or requirements validation were not sufficient. Given that quality problems are a major cause of project failure globally, this is an area needing significant improvement. QA Touch+1

  4. Reliance on overtime as a primary response.
    Sustained overtime and weekend work can lead to burnout, lower morale, and more defects, undermining long-term project success.

Successes and Failures of Release One

Key Successes

  • Schedule success: Release One went live on time, preserving credibility with the client.

  • Stakeholder communication: Regular status meetings allowed us to surface issues early, even if change handling was imperfect.

  • Learning opportunity: The issues encountered provide concrete lessons that can be built into Release Two planning.

Key Failures

  • Scope–time imbalance: Accepting scope changes without adjusting schedule or scope trade-offs was a planning failure.

  • Quality leakage: User-reported problems suggest that regression testing, exploratory testing, or user acceptance testing were insufficiently rigorous.

  • Proactive risk management gaps: We treated staff turnover, late changes, and quality concerns largely as reactive firefighting rather than anticipated risks.

These successes and failures align with common patterns in software projects, where unclear requirements, poor change control, and quality issues are among the top causes of failure. Sacramento State+2The University of Texas at Dallas+2

Major Challenges and How They Were Handled

  1. Team Attrition and Training

    • Challenge: Losing a developer and tester reduced capacity and slowed progress.

    • Response: We hired replacements quickly and assigned an experienced developer to train the new hire. While effective in the short term, this diverted that senior developer from feature work and contributed to overtime.

  2. Late Feature Change with Fixed Deadline

    • Challenge: A near-complete feature was significantly changed without flexibility on the release date.

    • Response: The team absorbed the change by working additional hours and re-prioritizing lower-value work informally. We did not formally quantify the impact or require written change approval.

  3. Post-Release Defects and Enhancement Requests

    • Challenge: Users encountered issues and requested additional changes and features.

    • Response: We logged the issues and enhancement requests for Release Two but had no established triage process or clear quality metrics to guide prioritization.

Alternate Strategies for Planning and Risk Mitigation

If planning Release One again, I would adopt the following strategies.

  1. Stronger Risk Management

    • Add resource attrition as a top risk with mitigations: cross-training, shared code ownership, and updated technical documentation so new hires can ramp faster.

    • Include late changes and scope creep as explicit risks, with a defined change control process and contingency buffers in schedule and budget. 3Pillar+1

  2. Formal Change Management

    • Implement a change control board (CCB) or at least a lightweight approval process with impact analysis (schedule, cost, scope, quality) for each change request. TrustEd Institute

    • Use prioritization techniques like MoSCoW or value vs. effort to decide which changes to include in the current release versus defer.

  3. Improved Quality Strategy

    • Introduce test-driven development (TDD) and automated unit tests for core modules, improving code quality and enabling safer refactoring. QA Touch+2conformiq.com+2

    • Build a regression test suite and integrate automated tests into the CI pipeline so that defects are detected earlier. Xoriant

    • Plan a dedicated stabilization sprint before release focused on fixing defects and performance tuning.

  4. More Rigorous Agile Retrospectives

    • Conduct structured retrospectives at the end of each sprint to identify what’s working and what needs improvement, feeding lessons into the next iteration. Atlassian+2Premier Agile+2

Recommendations for Managing Release Two

Based on Release One, I recommend the following for Release Two.

1. Methodology and Planning

  • Continue with agile Scrum, but enhance release planning: define a clear Release Two goal, break it into sprints, and maintain a prioritized product backlog that includes defects, change requests, and new features. Wrike

  • Set realistic capacity based on the current stable team size, avoiding assumptions that overtime will make up for lost productivity.

  • Reserve contingency (e.g., 10–15% of capacity) for unplanned work and production issues.

2. Change Management

  • Require all change requests (including new features and major changes) to be documented with business justification and urgency.

  • Perform an impact analysis on schedule, cost, and quality for each change and review it with the product owner and key stakeholders before approval. TrustEd Institute

  • Group approved changes into planned sprints; defer low-value or high-effort items to future releases if they threaten the timeline.

3. Quality Control

  • Define clear acceptance criteria for every user story and ensure tests (unit, integration, and user acceptance) are mapped to those criteria.

  • Expand test automation using TDD and regression suites, focusing first on the most business-critical workflows to reduce post-release defects. GeeksforGeeks+3QA Touch+3conformiq.com+3

  • Establish quality metrics (e.g., defect density, escaped defects, test coverage) and track them each sprint to identify trends early.

  • Involve representative end users in user acceptance testing to validate not just functionality but also usability and workflow fit.

4. Team Health and Communication

  • Replace sustained overtime with realistic sprint commitments and improved planning; use overtime only as a last resort.

  • Continue regular status meetings with stakeholders but add transparent reporting on capacity, risks, and change impacts.

  • Use sprint reviews and retrospectives to create a culture of continuous improvement and shared ownership of project outcomes. Atlassian+2Premier Agile+2

Conclusion

Release One of the XYZ Business Workflow project was a scheduling success but highlighted weaknesses in risk planning, change management, and quality control. These are common failure factors in software projects globally, but they can be addressed with disciplined processes and an agile mindset of continuous improvement. 3Pillar+1

By implementing stronger risk management, formal change control, enhanced quality practices, and healthier team planning, Release Two can deliver higher quality, respond more predictably to change, and reduce the likelihood of costly post-release issues.

References (APA, 10 sources)

Atlassian. (n.d.). What are agile retrospectives? Atlassian.

Conformiq. (2023, May 16). The six benefits of test-driven development. Conformiq. conformiq.com

FAETH Coaching. (n.d.). IT project failure rates: Facts and reasons. FAETH Coaching. Faeth Coaching

GeeksforGeeks. (2025). What is test driven development (TDD)? GeeksforGeeks. GeeksforGeeks

PremierAgile. (n.d.). The importance of agile retrospectives in continuous improvement. PremierAgile. Premier Agile

QATouch. (2024, June 5). What is test driven development? Benefits & examples. QATouch. QA Touch

Smartsheet. (2025). Free product & software release plan templates. Smartsheet.

Standish Group. (2024). Chaos report — A study about IT project management in software development. The Story. The Story

Trusted Institute. (n.d.). Change control process – PMBOK 7th edition. Trusted Institute. TrustEd Institute

Wrike. (n.d.). What is an agile release plan? Wrike Blog.

← Back to blog