I don’t know whether any of the readers has encountered issues like this:
Project’s requirement can never be recognized and approved by the client, or the understandings of requirements between different teams can never get aligned. Even worse, the project scope is always changing, which cause the team members impossible to finish the project scope in time.
The issues described above have been encountered by many project teams, especially in those software development projects.
In like manner, Kyle, who’s been in many software development projects as different roles (developer, tester, project manager… ) , has also encountered all those requirement issues. Base on the triangle theory of project management, project scope, cost and schedule interacts with each other. If the project scope can not be clearly defined by logical means or methods, or can not be controlled during the project process, or can not get aligned among different stakeholders, then, the project would possibly be damaged by these issues.
1 When a bunch of stakeholders propose various demands…
There is a practical case regarding to the situation of various stakeholders proposing different demands. Here is the case:
Kyle was a project manager. The project was to develop an at-home teaching software system for several primary schools. Due to the various stakeholders who’s proposing various demands, Kyle encountered unthinkable difficulties when collecting requirements. Even worse, several stakeholders had conflicted expectations on some key requirements.
Furthermore, it took Kyle lots of time to collect requirements from lots of stakeholders. After getting through various setbacks, Kyle finally created a requirement file which basically contained all requirements proposed by all of the stakeholders. After that, even though Kyle signed a contract and a development agreement base on the requirement file, new requirements and change requests was continually raised by the stakeholders during the project execution process. Those changes and new requirements were stated as “necessary modification” to the project. Kyle and his team were frustrated by all those changes.
Kyle and his team fell into a dilemma. To include all those new requirements which is not in the original scope of the contract, will definitely affect the project schedule and the quality of product. Not to include all those new requirements, will probably affect the final product, which would not get approval from the clients. It is believed that many project managers have been in similar dilemma and encountered similar issues. Then, as project manager, what should we do to solve the problems?
2 Methods of controlling scope
The description of project scope management in PMBOK is :
“Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Managing the project scope is primarily concerned with defining and controlling what is and is not included in the project. ”
In the processes of scope management, the first thing we should do to the project scope is to plan scope management. In this step “scope management plan” should be defined and it would document the methods of defining, validating, and controlling the scope of project and product. The next step is to collect requirements. In the upper case, it is in the process of collecting requirement where Kyle and his team encountered unthinkable issues and spent enormous time and energy on solving the problems.
Then, how can we avoid those issues from happening? Actually, we can use some methods and tools to verify and manage what the various stakeholders really want to achieve by the project.
Regarding to all those requirement issues, there are lots of tools and methods can be used, some of them were only created and developed in recent years. Tools like “user story” and so forth are quite useful for defining requirements under the situation of complicated requirements.
These tools have very high agility degree, as project manager, if we can choose the appropriate tool, then we can certainly acquire the real requirements.
The following step would be the process of define scope. In this process, we have to develop a detailed description of project and product based on the collected requirements, furthermore, to define the acceptance criteria of the product and deliverables. In the upper case, what we should do in this step is to sort out all the collected requirements and develop a complete detailed requirement file, and develop the “Definition of Done”. Based on the requirement file, contract and development agreement can be developed and signed by project manager and clients.
In the next step, which is very important but very easy to be neglected, is to create work breakdown structure (WBS). The key benefit of WBS to a project is to breakdown the entire project scope into smaller and more manageable components, and form a certain hierarchical structure of work. WBS makes the project scope much easier to be managed and provides a framework of what has to be delivered.
In the final step, which would happen when project team finish all the deliverables, is to invite the client to formally accept the products/deliverables. This step is called “Validate scope”.
3 Embrace change
Of course, there is another key process which is indispensable in the entire scope management, is “Control scope”. Usually, control scope means to restrict the project scope and limit the change of it, or even attempt to acquire client’s promise of keeping the project scope as stable as it can be.
In fact, that is not the case. The true meaning of control scope is :
“Make sure all changes of project scope can be identified in time, and use appropriate methods to process all those changes.”
Back to the upper case, lots of change requests can be identified during the project. Keeping us informed of all the change requests are very necessary.
There is a common saying: “nowaday software developments are all under the marketing environment of frequent requirement change, therefore, project manager and developers of software project have to learn to embrace the change.”
To embrace change does not mean “scope creep”. As project managers, we have to intentionally manage of what all those requirement changes would affect the project team, rather than to stop the requirements from changing or to indulge all the changes. Moreover, identify all the changes as early as possible would certainly be beneficial for the project. In addition, in the research area, the framework of agility can also be used to limit the cost of scope change to be minimum.