Controling the scope of a project in web development
When you work on a large development project, controlling the scope and changes is a very important task. Otherwise, the project could end up becoming unprofitable.
The system for controlling all the changes in the project scope should be clearly described in the project documentation, comply with the contract and be understood by all parties involved. It helps preventmisunderstandings. If the procedure of approving and authorising the suggested changes and assessing their cost is not followed strictly, it can lead to problems and possible legal issues.
Depending on the risks and investments involved with the proposed scope change, the verification procedures could be different. The higher the risks, the more advanced and stricter the control procedures need to be before the scope change can be approved, documented and added to the project scope.
The following documents are commonly used in the scope control process:
- Project Scope Statement
- Work Breakdown Structure (WBS)
- WBS Dictionary
- Project Scope Management Plan
- Performance reports
- Approved change requests
- Work Performance Information
Read more on the topic in this article.
It's important to make sure that every approved change is reflected in every document related to project management to avoid confusion. Also, the project manager has to ensure that all involved parties have access to all important documents.
The procedures of controlling changes through their lifecycle (from submission to authorisation and implementation) are described in the so-called Change Control System, which is one of the important tools of scope control. Other important tools and techniques include Change Control System, Variance Analysis and Re-planning.
Why is it important to formalise the change control system?
If the procedures of submitting, assessing, approving and implementing changes are not made as formal as possible, it can lead to various unpleasant situations.
Example 1:
The change requested by the client is misunderstood and, after implementation, the client discovers that the feature looks very different from what s/he expected. To put it right results in more work, wasted time and money, lowered profits and the relationship between the client and the web development company deteriorates.
Example 2:
The client keeps requesting changes that make it impossible to meet the deadline, but the deadline stays unchanged. What's worse, the client doesn't realise that implementing those changes means increase of the cost of the projects. Result: difficult negotiations full of misunderstandings; the client threatens to sue the vendor; the vendor threatens to quit the project; developers have to work overtime.
Example 3:
The change request hasn't been approved yet, but due to bad communications the developers have started to implement it. Later, the client changes the requirements or decides not to implement the requested feature at all.
A good project manager knows how to be diplomatic, but at the same time ensures strict and faithful observation of rules and procedures by all parties involved in the development of the project. After all, smooth and successful development and painless and precise handling of the change requests is in everyone's interest. Neither the client nor the web development company is interested in discord.
Post new comment