Government regulatory project with the following details:
Revenue: $5 million
Penalty: $1 million if not completed within 6 months
Team: 10 developers, 2 testers
Timeline:
0.5 months for requirement gathering
4.5 months for development and UAT
1 month for automation testing
The issue: 2 months have already passed just on requirements gathering, and now the team is panicking. As a project manager, I have the opportunity to talk to 4 key roles to address the delays:
1. The customer
2. HR
3. Project Team
4. My manager
Given the time pressure and financial stakes, how would you approach this situation?
I’d love to hear your thoughts, experiences, or recommendations!
The original anticipated time was .5 months for requirement gathering. How did the team exceed that by 1.5 months? Any discussions before the team got to that point? Any discussions on how much more time will be needed? I think a conversation has to be had with Project team and definitely the customer. You don't want the customer to be blind sided by a delay.
...
1 reply by Bulle Sreekanth
Sep 26, 2024 1:07 AM
Bulle Sreekanth
...
Thank you for your feedback! You're absolutely right—there should have been discussions earlier when it became clear that the requirements phase was taking longer than anticipated. Unfortunately, due to the complexity of the requirements and some unforeseen challenges, we went beyond the planned timeframe. I will definitely have a candid conversation with both the project team and the customer to align expectations and determine how much additional time will be required. Keeping the customer informed is crucial, and I appreciate you highlighting that. Thank you
I'd echo Danielle's comments - projects get late one day at a time so this kind of schedule variance should have been identified much earlier and if the root cause was unavailability of customer SMEs to participate in requirements gathering that should have been escalated.
Given that you have 4.5 months to go, one option might be to focus on a minimally acceptable product where some of the expected automation is handled by manual procedures. Regulatory compliance projects rarely specify the "how" - they focus more on the "what".
In any event, start by taking it to the team and developing options and then get the support of your leadership for those before going to the client.
Kiron
...
1 reply by Bulle Sreekanth
Sep 26, 2024 1:08 AM
Bulle Sreekanth
...
Thanks for your input, I completely agree with your approach. This delay should have been flagged sooner, and I’ll be addressing that in the team discussion. You raise a great point about focusing on delivering a minimally acceptable product. Given the regulatory nature of the project, as long as we meet the "what" (compliance), the "how" might be adjusted, especially if automation could be substituted with manual processes initially.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
My recommendation (and it is not a joke) is using PMI´s Infinity to put a prompt there and see the results. The same you can do with ChatGPT. You have "universal knowledge" inside it. Saving Changes...
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Bulle, my thoughts are in line with Danielle and Kiron. You need to start working on a mitigation plan soonest possible in collaboration with both the Project Team and Client. This is a serious situation that needs to be dealt with ASAP given that it is a government regulatory project with a contractual penalty. Saving Changes...
The original anticipated time was .5 months for requirement gathering. How did the team exceed that by 1.5 months? Any discussions before the team got to that point? Any discussions on how much more time will be needed? I think a conversation has to be had with Project team and definitely the customer. You don't want the customer to be blind sided by a delay.
Thank you for your feedback! You're absolutely right—there should have been discussions earlier when it became clear that the requirements phase was taking longer than anticipated. Unfortunately, due to the complexity of the requirements and some unforeseen challenges, we went beyond the planned timeframe. I will definitely have a candid conversation with both the project team and the customer to align expectations and determine how much additional time will be required. Keeping the customer informed is crucial, and I appreciate you highlighting that. Thank you Saving Changes...
I'd echo Danielle's comments - projects get late one day at a time so this kind of schedule variance should have been identified much earlier and if the root cause was unavailability of customer SMEs to participate in requirements gathering that should have been escalated.
Given that you have 4.5 months to go, one option might be to focus on a minimally acceptable product where some of the expected automation is handled by manual procedures. Regulatory compliance projects rarely specify the "how" - they focus more on the "what".
In any event, start by taking it to the team and developing options and then get the support of your leadership for those before going to the client.
Kiron
Thanks for your input, I completely agree with your approach. This delay should have been flagged sooner, and I’ll be addressing that in the team discussion. You raise a great point about focusing on delivering a minimally acceptable product. Given the regulatory nature of the project, as long as we meet the "what" (compliance), the "how" might be adjusted, especially if automation could be substituted with manual processes initially. Saving Changes...
Keith MelvinSumaria Systems, LLCDayton, OH, United States
Bulle, that planned seem flawed at the onset. If you were taking on something you hadn't done before, how could you determine what the proper time commitment would be for requirements planning or any of the other project constraints.
As others have stated, it's time to dive deep into mitigation strategies (can you break the project down and deliver something small), but first, have a candid discussion with stakeholders on where you are. It's truly ok to re-baseline if everyone agrees to it. Saving Changes...