Even though defining all the project attributes right from the start is essential, project managers sometimes fail to compile them all effectively, thereby leading to roadblocks later on. So, what should be the approach to create a comprehensive project scope document that can help avoid discrepancies?
Project Scope Documentation
Forum Sponsor
Top Posters
Julian Pegg
1 posts
Peter Nagy
2 posts
Raymund de Laza
17 posts
Syed_Asad
0 posts
Tony Greyvenstein
0 posts
Ahmed Al-Jubouri
13 posts
Umar Alvi
3 posts
Sibusiso Mahlalela
0 posts
Michael Samanyayi
3 posts
Simon Gumede
0 posts
The client's role should be to define the scope of the project - the project is intended to deliver a solution to a requirement the client has. However, clients are rarely capable of fully defining their needs and require assistance from the SMEs in the delivery team.
Requirements gathering is basically a structured investigation: https://mosaicprojects.com.au/PMKI-PBK-015.php#Process1
The way this is done depends on the project’s relationship to the client and the way the project is being managed. Agile projects evolve, other ‘hard’ projects need the scope defined up front. But this can be difficult, on mega-projects it is not uncommon to see up to 20% of the scope missed from the initial contract documents. There’s a series of reports on this, see the ‘Scope for Improvement’ series at: https://mosaicprojects.com.au/PMKI-ITC-010.php#Overview
This is the area of Requirements Engineering. ALL the contract documents are deconstructed into a deliverables list which are tracked throughout the project. When you've handed over all requirements job finished
Peter
you should re-take off the documents and do ANOTHER estimate to make sure that you did not miss anything because a lot of the times the person taking of the inital bid estimate are not the same people excuting the work.