I have project requirement, which was considered as "can be implemented" during design phase.Now we in QA phase, requirement is further broken down into different scenario(valid one's) by QA and my development team is facing technical challenges in implementing all of these scenarios.
We are approaching Go Live a week from today.
1. As project manager, can I negotiate with client on scope of requirement. If yes, how I do go about 2. Should I be honest enough that lack of technical skill is preventing us from implementation
Note: I will not have any future release related to this requirement & need to release development resources after project ends next week Saving Changes...
It sounds like you're in a tough situation, but I have to ask, is it really a lack of technical skill that will prevent you from delivering the new functionality? You are a week away from Go Live, and you're still testing. If you had someone who could develop the new functionality before Go Live, it still might be a bad idea.
If the new functionality affects anything that has already been tested, you'll have to test it over again. If it affects any developed functionality that has not been tested, yet, you have to wait to test it until the new functionality is ready to test.
Do you have the time to develop the new functionality and test everything it affects before Go Live? If the answer is no, you need to be honest with the customer about that. All the technical skill in the world may not be enough to help you.
If you don't have someone with the technical skill to develop the new functionality, you don't have anyone with the ability to accurately tell you how long it would take to develop it.
Technically, Change Management can be done at any point during a project, as long as all parties understand and are willing to accept the impact of the change. A major change just before Go Live can jeopardize the Go Live date, but it may be what is needed to go live with a usable product. Explain the situation to your customer and provide options for how to proceed, including any financial impacts. Let the customer make an informed decision. Saving Changes...
Deepesh RammoorthyICT Project Manager ( PMP®AgilePM®Certified ScrumMaster® (CSM®))| Australian Red Cross Blood ServiceTarneit, Vic, Australia
Great Suggestion Aaron .
I agree With Aaron
Sharath, an honest presentation of the facts and the current situation along with financial , time and scope impacts to the Sponsor/Customer will be the best course of action.
Yes you can definitely say to the customer/sponsor that you are facing some technical challenges and may need more time and assistance from your manager to procure some experts from the market.
There's nothing to hide if some technical implementation is more challenging than the internal resources can handle.
The current resources were recruited by their Functional managers to best suit projects and requirements at that particular point in time and the challenges presented by your current project in no way undermine their technical abilities. You just need to find someone with a broader range or specific skillset to tackle your current challenge.
If your team lacks technical skills, you may have to approach your own boss or the team's functional manager to best assist you with other/more experienced technical resources. It may be that you may need to outsource to another agency to get some technical resources to come in and assist you. All this means is more time and scope which you don't currently have because you are already in testing phase and its incumbent on you to produce a functional product that works, rather than a product with new features that cannot be tested in time.
If the customer agrees with the scope change and the change request, you should formally get it registered with the change control board.
You need to also confirm with your team whether your team is able to deliver to the original scope (The scope that included "must be delivered") by the original deadline date.
From a project manager's perspective having the best resources and most accurate estimation will help you provide the best service to the customer. Also, you must mitigate or avoid the risk at all times of getting a defect ridden product out of the door. Remember, you need to build quality into the design to make sure you don't have a lot of quality issues while testing Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
First, you have to be transparent and honest. Clearly explain the situation, possible solutions, and resultant impacts. This provides necessary details to empower an educated decision. Seems like there are two choices, de-scope, or move the target date. The 'how did this happen' can be part of the lessons learned exercise.
There simply cannot be any coding activities this close to Go-Live. That right there is the biggest risk of them all. Saving Changes...
Aaron is spot on with this one. Best not to sugar coat with so little hours left on this contract. Provide information to client so they can get information to the decision makers. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I do not agree with Aaron`s statement in genral. I faced this type of situations lot of times. Including today at project/program level. All changes are welcome. BUT everybody must understand and agree with the change management process in place. AND the project manager must not be the person to decide about the change. The project manager is accountable to create all needed to able the right people to decide about the change. That is critical to understand and it is most of the time missing.
...
1 reply by Aaron Porter
Apr 06, 2017 10:29 AM
Aaron Porter
...
Sergio, I'm not sure what you disagree with. I stated "Change Management can be done at any point during a project, as long as all parties understand and are willing to accept the impact of the change." You said something similar. I did not say anything about the project manager being the decision maker about the change or anything contrary to what you have written.
What am I missing?
Saving Changes...
S RajasekarSenior Project Manager| AllscriptsBangalore, Karnataka, India
Technical challenges tend to happen. Estimation, design..etc are based on certain assumption/expertise so things go wrong…..expect the unexpected
Question is QA team should have come up with scenarios/test cases and should have been reviewed with dev..etc, Why are we breaking down scenarios/test case at last moment when about to execute ,there is a clear miss. This is not new its keep happening..we are not learning from our mistakes
It is time to see what can be done
1. What is the impact of not completing this feature/requirement for client/project on committed timeline
2. Without time constraint if we have to complete what it takes to do (estimate)
3. Have you done alternative analysis
With above details present the case with customer , let them take the call…. GO Live/No GO Live
Happened so can’t go back and change what happened (Only can do RCA ?) , Accept the reality see what next Saving Changes...
Sergio nailed it, to me the answer is always "yes" but what are you/they willing to do for it. Solid change management will structure the process, but ultimately late changes will always result in resetting of expectations and new timelines. The decision needs to be made on what functionality is truly needed and wanted. All that aside, there sounds like more issues to the story than just negotiating scope. As Andrew and others said, be transparent and honest - better now than after it's released. Saving Changes...
I do not agree with Aaron`s statement in genral. I faced this type of situations lot of times. Including today at project/program level. All changes are welcome. BUT everybody must understand and agree with the change management process in place. AND the project manager must not be the person to decide about the change. The project manager is accountable to create all needed to able the right people to decide about the change. That is critical to understand and it is most of the time missing.
Sergio, I'm not sure what you disagree with. I stated "Change Management can be done at any point during a project, as long as all parties understand and are willing to accept the impact of the change." You said something similar. I did not say anything about the project manager being the decision maker about the change or anything contrary to what you have written.
What am I missing?
...
1 reply by Sergio Luis Conte
Apr 06, 2017 10:45 AM
Sergio Luis Conte
...
I understood that you are pointed out that the project manager is in charge to decide about the change. The project manager has nothing to do besides to activate the generation of all information needed to be part of the change management process. English is not my first language so please sorry if I did not understand your comment.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Apr 06, 2017 10:29 AM
Replying to Aaron Porter
...
Sergio, I'm not sure what you disagree with. I stated "Change Management can be done at any point during a project, as long as all parties understand and are willing to accept the impact of the change." You said something similar. I did not say anything about the project manager being the decision maker about the change or anything contrary to what you have written.
What am I missing?
I understood that you are pointed out that the project manager is in charge to decide about the change. The project manager has nothing to do besides to activate the generation of all information needed to be part of the change management process. English is not my first language so please sorry if I did not understand your comment.
...
1 reply by Aaron Porter
Apr 06, 2017 12:02 PM
Aaron Porter
...
No worries. My point was that Sharath should explain the situation to the customer and let the customer decide how he or she wants to proceed - either accept what can be delivered or initiate a change to include the additional functionality.