The project scope is developed by the project manager and basically defines the products and deliverables to be produced during the project. The project scope takes the inputs from the user requirements and business case, and it structures the project into exactly what needs to be performed. In other words, it documents what the intended business goals are.
A common problem encountered with project scope is that the majority of initial client discussions and negotiations take place with the client and marketing executive and are carried out in isolation from the solution team. The project manager is rarely involved early on and it’s not until later that he gets to set things right in his project schedule using a tool like Seavus’ Project Viewer. Unfortunately, the early schedule is often created by the marketing executive with the goal of ‘selling the project’ in mind.
The ultimate goal of marketing executives is to market and sell solutions to clients, and when a solution is agreed upon, the client is left with the belief that it will get that specific solution. However, the technical details are left up to the solution team to resolve, and in many cases, the scope of the project changes. The project manager should work closely with the marketing manager and business analyst in order to negotiate the complete scope of work. Remember that if the scope is left untouched and uncontrolled, it is probable that your project will come in over budget and behind schedule.
It’s important that the project solution team meet with the client within a few days to initiate the kick-off meeting and start defining the scope in more detail. This is where the business analysts and project manager start playing a very valuable role by providing the appearance, the knowledge, and the commitment to assist the client in solving its business problems. The project analysis team should include the client as part of the team in order to verify that the scope is defined accurately. One way to present the project scope is through the use of the project management plan. Another is by capturing the requirements and creating a follow-up requirements definition document – both of which should be signoff/approval points with the customer. The purpose of either of these documents is to allow stakeholders to determine quickly if a given requirement should possibly be implemented by the project. Whatever document is ultimately used, the following should be identified:
- What the project scope is
- What the project is not
- How it will be managed
- The risks of scope change
- How scope changes will be integrated into the project
It is very likely that most projects will have some degree of scope change during their life cycle. Project managers should clearly understand what is included or excluded from the project, and what this effect will likely have on the entire project.