While working in IT at Regatta University, you are assigned a second project: up
ID: 3585570 • Letter: W
Question
While working in IT at Regatta University, you are assigned a second project: updating the “look and feel” of the of the student services portal. This project runs concurrently with the student degree progress project. Further, because of the interwoven nature of the two codes, the graphical user interface (GUI) update must be deployed at the same time as the student degree progress project. As the GUI project progresses, you realize that its schedule is starting to slip and the GUI project is falling behind. This is causing a major risk to the scheduled delivery of the student degree progress project as well. In your discussion post, do the following: Using the triple constraints, discuss at least one factor (schedule, cost, scope) that could be changed as a solution for ensuring that both projects are delivered at the same time. Review the list of project risks in the Project Management Documents spreadsheet. Will the solution proposed in Step increase the likelihood or potential severity of any of these risks? Identify and describe any new risks raised by the proposed solution. In your responses to classmates, be sure to note areas of similarities and differences in their analyses and your own. Consider the best course of action for keeping both projects on track. As you can see, managing projects can be complex and often requires careful analysis of problems and solutions.
Project Risk Likelihood Implications There is a risk that severe weather in Sailcloth, Maine (the main campus that houses the development team), will close the campus and impact progress. Medium There is a risk that the ambiguity in the project scope (it only defines "graphical element" but not what type) will lead to requirement changes by the stakeholder during development, affecting both the budget and schedule. High There is a risk that sign-off on project deliverables (charter, Gantt chart, product approval, etc.) from project sponsors and stakeholders exceeds the allotted time. This decision delay will impact the progress schedule. Low There is a risk for rollout issues when deploying to production due to complexity of merging code with the "go-live" of another project on the same system. High Two projects are currently being developed at the same time in the same code base. Delays to the secondary project will cause delays to the Student Progress go-live. High The student portal where the project will be deployed is a high-availability system and is expected to be accessible for students 24/7. There is a risk that the large number of changes occurring during go-live could take the system offline, temporarily impacting system availability. Low There is a risk that an interpersonal conflict will arise within the team, impacting the human resources assigned to the project and potentially impacting the allotted schedule. LowExplanation / Answer
Project Risk
Likelihood
Implications and Improvements
There is a risk that severe weather in Sailcloth, Maine (the main campus that houses the development team), will close the campus and impact progress.
Low to Medium
development but, up to some degree can be managed.
There is a risk that the ambiguity in the project scope (it only defines "graphical element" but not what type) will lead to requirement changes by the stakeholder during development, affecting both the budget and schedule.
High(Critical)
will progress be so deep that, resolution will be very tricky and can threaten
not only deadline but the project itself. So we need to take care
and come up with minimum baseline understanding document
which both engineering and stakeholders agree on before hand.
Milestones and a working prototype which can be demo-ed to the
Stakeholder and feedback could be received in middle rather than
In last.
There is a risk that sign-off on project deliverables (charter, Gantt chart, product approval, etc.) from project sponsors and stakeholders exceeds the allotted time. This decision delay will impact the progress schedule.
Low
or sponsors which is very important, indeed!. We should internally
come up with number of finished feature we can deliver. Many time
than not, a less number of working things are better than many broken
things. And business people value this outlook.
There is a risk for rollout issues when deploying to production due to complexity of merging code with the "go-live" of another project on the same system.
High
Even though we might have to allot some time from the actual dev
work. 2 or 3 less won’t hurt the overall product as much as a
broken system altogether.
Two projects are currently being developed at the same time in the same code base. Delays to the secondary project will cause delays to the Student Progress go-live.
High
System so that coupling could be reduced and some kind of endpoints
Must be there in system where 2 systems connect, it should not
Be linked at all place at all time.
We are aware of its timing and position.
The student portal where the project will be deployed is a high-availability system and is expected to be accessible for students 24/7. There is a risk that the large number of changes occurring during go-live could take the system offline, temporarily impacting system availability.
Low
More features will exponentially increase the systems complexity
And it will be harder to control thereafter.
There is a risk that an interpersonal conflict will arise within the team, impacting the human resources assigned to the project and potentially impacting the allotted schedule.
Low to medium.
Of manager comes in picture.
critical, when people are not content with their supervisor or work pressure.
Team leads and managers need to respect and coordinate with their
Some additional challenges or suggestions:
Deliver good, though its less.
Project Risk
Likelihood
Implications and Improvements
There is a risk that severe weather in Sailcloth, Maine (the main campus that houses the development team), will close the campus and impact progress.
Low to Medium
- Though external factors are very much real and can affect the prod
development but, up to some degree can be managed.
There is a risk that the ambiguity in the project scope (it only defines "graphical element" but not what type) will lead to requirement changes by the stakeholder during development, affecting both the budget and schedule.
High(Critical)
- This can lead to far-fetched re work scenarios, when development
will progress be so deep that, resolution will be very tricky and can threaten
not only deadline but the project itself. So we need to take care
and come up with minimum baseline understanding document
which both engineering and stakeholders agree on before hand.
- We must go with iterative dev process where we finish certain
Milestones and a working prototype which can be demo-ed to the
Stakeholder and feedback could be received in middle rather than
In last.
There is a risk that sign-off on project deliverables (charter, Gantt chart, product approval, etc.) from project sponsors and stakeholders exceeds the allotted time. This decision delay will impact the progress schedule.
Low
- Though implmentation of some important features from the perspective of stakeholder
or sponsors which is very important, indeed!. We should internally
come up with number of finished feature we can deliver. Many time
than not, a less number of working things are better than many broken
things. And business people value this outlook.
There is a risk for rollout issues when deploying to production due to complexity of merging code with the "go-live" of another project on the same system.
High
- A through integration testing is must and must be taken into the,
Even though we might have to allot some time from the actual dev
work. 2 or 3 less won’t hurt the overall product as much as a
broken system altogether.
- Importance of this phase is very high and is critical to the project.
Two projects are currently being developed at the same time in the same code base. Delays to the secondary project will cause delays to the Student Progress go-live.
High
- We need to consult with better architecture for the design of the
System so that coupling could be reduced and some kind of endpoints
Must be there in system where 2 systems connect, it should not
Be linked at all place at all time.
- Dependency cannot be zeroed down, but could be defined so that
We are aware of its timing and position.
The student portal where the project will be deployed is a high-availability system and is expected to be accessible for students 24/7. There is a risk that the large number of changes occurring during go-live could take the system offline, temporarily impacting system availability.
Low
- Beyond certain time frame all dev activity will freeze, cramming down
More features will exponentially increase the systems complexity
And it will be harder to control thereafter.
- Once freezed, a through testing by either cross or with dedicated testers
There is a risk that an interpersonal conflict will arise within the team, impacting the human resources assigned to the project and potentially impacting the allotted schedule.
Low to medium.
- People conflicts can happen for millions of reasons that’s where role
Of manager comes in picture.
- the effect it can have on project can range from medium to even
critical, when people are not content with their supervisor or work pressure.
Team leads and managers need to respect and coordinate with their
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.