<aside> ⛳ You are in the process of initiating a project. Future product: messеnger app like Watsapp for iOS, Android, Web. Your development team roughly estimated the work at 6 months, and the customer wants to receive a release in 2 months. What are the options for solving this problem and which option would you prefer? Depending on the chosen techniques and methods, identify potential risks in the adopted action plan.
</aside>
A PM can apply one of the Schedule Compression techniques (fast-tracking or crashing) to determine whether it is realistic to achieve 66% schedule compression (from 6 to 2 months), without adjusting other project baselines (budget and scope). Resource levelling can also be an option.
Risks of each techinque:
1. Fast-tracking - normally causes some amount of rework and lower quality due to overlapping work items on a critical path.
2. Crashing - increases budget overrun risk and people burnout risk, should be used as a last resort measure.
3. Resource levelling - might have to utilize contigency reserve for that measure to work out, also adding more people on the team increases communication overhead and, contrary to expectations, slows down team's pace most of the time.
Since 66% schedule compression is hardly achievable without cutting scope and (maybe) increasing budget due to potential resource additions, my action plan would look like that:
1. Compress the schdeule, check how much time we have managed to win
2. Make a list of suggested feature simplification ideas with new estimates next to the original ones
3. Make a new baseline based on an assumption that ALL ideas have been accepted.
4. Present a new schedule to the customer and discuss ideas for feature simplifications (or removal in some cases) and new baseline schedule
5. Get his buy-in and approval for a new baseline of schedule and scope
6. Make changes to your project plan (to its baselines) and backlog in Jira
<aside> ⛳ You are a project manager on an ongoing development project. You are responsible for the iOS part and the Back-end part is supplied by the client's side. You have an extremely strict deadline due to the launching of the marketing campaign. There are some pauses on the back-end team side which cause blockers for your team. In addition, the client asks you to add two extra features for the marketing campaign. Those features are vital for launching the product and it makes no sense to roll out the app without them. What would you do to keep stakeholders satisfied? Please write an email with a response.
</aside>
In this case, we're faced with a risk of integrating with third-party developement team that fired in the middle of the project. First, a PM should check with the schedule baseline and see how much float (slack) he allowed for that external (and mandatory) dependecy in the schedule: if this delay is within the float limits, a PM should communicate with somebody from management staff of the back-end team to work out ways of removing blockers from the critical path of the project. A PM can suggest their solutions as well: adding more senior back-end enigneers on the team, remove any communication blockers between the back-end and iOS teams etc.
As for adding new features to the release scope, this request must be treated as a request for change, therefore it must be taken through a Change Request Process established on that project. If CCB decides that this change must be included in the release scope, considering all risks, a PM can add those 2 new features to the scope. I wouldn't write a separate email, since there's only one short response to such request - let's review this CR following our process with CCB and then make a final decision.
****
<aside> ⛳ Today is the last day of the sprint. A demo meeting is scheduled at 5 p.m. From the 7 user stories planned for this sprint, only one is in Done status and is fully ready to be demonstrated to your stakeholders. Three user stories have minor UI defects, that do not allow you to close these 3 stories. The remaining 3 have not been tested yet. This morning you found out that the staging environment (which you usually show the demo on) is broken because of some technical reasons. The estimated time for the fix is 16:00. Describe your actions in this situation: will you conduct a demo meeting or not. If yes, what user stories will you show? If not, your next steps and actions. Compose the appropriate email to your stakeholders with a description of your action plan.
</aside>
My decision would be to demo 1 tested story and other 3 with minor UI defects (on dev server - dicey, but better than nothing at all, we can all agree to suspend any merges to dev on demo day, everybody should work locally with their code), explaining to the customer (or a PO) that they would see other 3 stories on the staging on day 1-2 of the next sprint.
------
Hi [client_name],
Hope you are doing good!
I am writing this email to inform you about changes in the plan of upcoming demo today at 17:00 GMT.
We are ready to demo stories X (Jira link), Y (Jira link), Z (Jira link), B (Jira link); and these stories (list of issues keys) we will be able to demo 2 days from today. This is due to unexpected risks that caused a delay in testing during the sprint (more details on the call).
Demo will be conducted using our dev environment because the staging has been down since morning. Our DevOps specialist has been working on that issue, and his estimate that it will be up and running again before 16:00 GMT. Regardless of the fix time, I would still use dev env for this demo because we are confident that on dev those stories do work well and are demonstrable.
Staying in touch,
Stas
P.S.: after the end of the sprint we're going to hold a team retrospective to discover all root causes that led to that and how we can prevent the same issue from happening in the sprints to come. I will share the results of the retro with you and discuss them, if you have any comments to add.