Project scope in the contract is full holes which is leave a lot of guess to customer expectations... Do we call a do over or continue to block and tackle through the whole project? Saving Changes...
Bala S DuvvuriProject Manager| ShellBangalore, Karnataka, India
I would suggest
1.Understand what is the reason behind leaving lot of holes in the scope.
2.Complete the scope freezing first by explaining the impact of doing the project without scope freeze.
3.Have a Change control board(CCB) and explain it roles/responsibilities to all the stakeholders
4.Explain to all the stakeholders that no change will be considered before approved by CCB
5.Once a new change comes analyze the change and find out its impact and put it in front of CCB for approval.
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
I second Bala's feedback and I would say, that at this stage of the project which I assume it is in the execution phase, you should work on covering all major holes through change requests. Saving Changes...
Hooi Nee SauIT Project Manager| ,Kuala Lumpur, Malaysia
Agreed with 2 comments above. I would suggest to establish the change control process first.
Anything that not stated clearly in contract consider as change request (CR). CR can be chargeable or non-chargeable CR. The key things are to avoid any scope creep in project. Newly found gaps shall documented properly during project execution. Saving Changes...
Markus KopkoAI Enabler for Project & Program Mgmt | Founder PMotion.ai / The PM
AI Coach| PMotion.aiHamburg, Hamburg, Germany
Hello,
all what is written already is complelty right and i would underline it, but i would also add another aspect here.
I am not sure if establishing a change control board/process is would solve all the problmes coming along with such a obv. bad scope definition.
Cause the customer has to accept that not only everything what is missing in the scope defintión has to be handled by a CR (that should be easy enough), but also everything what is not clearly defined in the scope definition.
And what will happen if the customer saif, no it isn't a change request cause it is written in the scope and i have understnad it like this ...
I guess there will be still a lot of discussion/negotiation even a CR process is established and accepted.
And that show all the dilemma of a bad/missing business analysis/reqirement engineering. I guess this is reason why BA is becoming more and more important.
Regards,
Markus
...
1 reply by Rami Kaibni
Feb 22, 2016 10:00 AM
Rami Kaibni
...
Hi Markus,
How is a business analyst involved in defining scope as you've noted in your comment ?
Thanks,
RK
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Trying to add something to great comments above let me say that the first thing I do each time I start an initiative is to clarify the change management process no matter if is an internal or external project. All changes are welcome but everybody have to be aware that the changes will pass through a process to decide to procede or not and everybody have to be aware that they will be the owner of the change not the project manager. Saving Changes...
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Feb 22, 2016 2:58 AM
Replying to Markus Kopko
...
Hello,
all what is written already is complelty right and i would underline it, but i would also add another aspect here.
I am not sure if establishing a change control board/process is would solve all the problmes coming along with such a obv. bad scope definition.
Cause the customer has to accept that not only everything what is missing in the scope defintión has to be handled by a CR (that should be easy enough), but also everything what is not clearly defined in the scope definition.
And what will happen if the customer saif, no it isn't a change request cause it is written in the scope and i have understnad it like this ...
I guess there will be still a lot of discussion/negotiation even a CR process is established and accepted.
And that show all the dilemma of a bad/missing business analysis/reqirement engineering. I guess this is reason why BA is becoming more and more important.
Regards,
Markus
Hi Markus,
How is a business analyst involved in defining scope as you've noted in your comment ?
Thanks,
RK
...
1 reply by Markus Kopko
Feb 22, 2016 10:05 AM
Markus Kopko
...
Hi Rami,
as far as i know and from my experience the scope is developed out of the results of business analysis/requirements engineering; done by the project manager/team of course. Am i wrong?
Saving Changes...
Markus KopkoAI Enabler for Project & Program Mgmt | Founder PMotion.ai / The PM
AI Coach| PMotion.aiHamburg, Hamburg, Germany
Feb 22, 2016 10:00 AM
Replying to Rami Kaibni
...
Hi Markus,
How is a business analyst involved in defining scope as you've noted in your comment ?
Thanks,
RK
Hi Rami,
as far as i know and from my experience the scope is developed out of the results of business analysis/requirements engineering; done by the project manager/team of course. Am i wrong?
...
1 reply by Rami Kaibni
Feb 22, 2016 10:35 AM
Rami Kaibni
...
Hi Marlus, I never said you are wrong but I was just wondering how does having a BA improve the scope definition. IMHO, I personally see no relation. The BA analyzes the business opportunity and defines it. This analysis is reflected in the project charter along with high level requirements which are then broken down into details during the planning phase. If there are gaps in the scope, then there should be something wrong during creating the WBS or defining the Procurement Scope of Work.
If the project scope was not in line with the business plan then that is another story and the project is taking another diversion and should be totally redirected.
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Feb 22, 2016 10:05 AM
Replying to Markus Kopko
...
Hi Rami,
as far as i know and from my experience the scope is developed out of the results of business analysis/requirements engineering; done by the project manager/team of course. Am i wrong?
Hi Marlus, I never said you are wrong but I was just wondering how does having a BA improve the scope definition. IMHO, I personally see no relation. The BA analyzes the business opportunity and defines it. This analysis is reflected in the project charter along with high level requirements which are then broken down into details during the planning phase. If there are gaps in the scope, then there should be something wrong during creating the WBS or defining the Procurement Scope of Work.
If the project scope was not in line with the business plan then that is another story and the project is taking another diversion and should be totally redirected.
...
1 reply by Markus Kopko
Feb 22, 2016 10:51 AM
Markus Kopko
...
Hi Rami,
like said before, it is absolutly ok to disagree ... even between the two of us! ... ;)
However, i see definitivly a relattionship there. Well, scope is defined basing on the requirements (may be not alone on them but a big portion of the scope for sure), right?
And the requirements (and as far as i know not only the high level) came out of the business analysis process ( as long as i understand PMIs BA practice guide right on that topic).
Yes, there are a lot of overlapping in doing requirements planning/engineering/analysis between BA and PM (you can see so if you just searching for the so called "colaboration points" in the BA practice guide).
So, IMHO BA could be a root cause for a bad/uncomplete scope definition. Or i got something terrible wrong with the BA practice guide.
Regards,
Markus
Saving Changes...
Markus KopkoAI Enabler for Project & Program Mgmt | Founder PMotion.ai / The PM
AI Coach| PMotion.aiHamburg, Hamburg, Germany
Feb 22, 2016 10:35 AM
Replying to Rami Kaibni
...
Hi Marlus, I never said you are wrong but I was just wondering how does having a BA improve the scope definition. IMHO, I personally see no relation. The BA analyzes the business opportunity and defines it. This analysis is reflected in the project charter along with high level requirements which are then broken down into details during the planning phase. If there are gaps in the scope, then there should be something wrong during creating the WBS or defining the Procurement Scope of Work.
If the project scope was not in line with the business plan then that is another story and the project is taking another diversion and should be totally redirected.
Hi Rami,
like said before, it is absolutly ok to disagree ... even between the two of us! ... ;)
However, i see definitivly a relattionship there. Well, scope is defined basing on the requirements (may be not alone on them but a big portion of the scope for sure), right?
And the requirements (and as far as i know not only the high level) came out of the business analysis process ( as long as i understand PMIs BA practice guide right on that topic).
Yes, there are a lot of overlapping in doing requirements planning/engineering/analysis between BA and PM (you can see so if you just searching for the so called "colaboration points" in the BA practice guide).
So, IMHO BA could be a root cause for a bad/uncomplete scope definition. Or i got something terrible wrong with the BA practice guide.
Regards,
Markus Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The business analyst is key to define the scope. Fully agree with Markus. We need to understand that there are two types of scope: product scope and project scope. Project scope (in charge of project manager) is defined from product scope (in charge of business analyst). And more important: the business analyst is the role that will help the organization to define and create the right solution (where solution is equal to "the thing" to be created PLUS "the process" to create it - the project). Remember, is a role and most of us in the very begining have performed both roles (and perhaps some of us we still performing both) but the skills are totally diferent. Saving Changes...