When it comes to project management, beginning well is important and helps the project build momentum. Scope risk, however, may threaten the earliest stages of project work, when scope is defined.
Project managers must key in on the triple constraint scope, schedule, and cost throughout the project lifecycle. Of the three, scope risk should be considered first and early on. Scope risk also is most significant, because it could reflect a project that is literally impossible to accomplish. Scope risk analysis helps uncover a feasible project or one beyond the advancement of technology. It reveals loose ends in requirements, and guards against creep. Scope risk analysis also helps in management of software & hardware defects along with system integration setbacks. Early decisions to adjust or abandon a project are critical on projects that have significant scope risk.
Scope and Requirements Mismatch
In a nutshell requirements are what the customer wants and scope is the work to be done. There must be a realistic or suitable match between the requirements and the scope of work. Unrealistic requirements may make the scope of work impossible; requirements must correlate to feasible scope.
One of the more noteworthy examples of requirements caused improbable scope comes from the 19th century and the French effort to construct a canal connecting the Atlantic and Pacific oceans. The project manager of the French canal project, Ferdinand de Lesseps, was adamant in his requirement that the canal be au niveau de la mer (at sea level).
An at sea level canal worked well for de Lesseps when he managed the effort to construct an at sea level canal through Suez. The Suez Canal project joining the Mediterranean and Red Seas was a huge success and de Lesseps became an instant hero. But his star fell hard while trying to repeat his success by managing a canal project to connect the Atlantic and Pacific Oceans at Panama. A canal au niveau de la mer and sans écluses (without locks), was a near impossibility at Panama, although successfully achieved at Suez. And when de Lesseps finally acquiesced to a canal with locks, it was too late. By then his financial backing had stumbled, and his project failed.
Despite the advantage at Panama of a shorter distance, the Panama Canal was a significantly larger and more baffling project than Suez. The maximum elevation along the Suez Canal was 50 feet above sea level. Panama, however, was covered by steep little mountains and the maximum elevation of the canal line would prove to be 339-1/2 feet. And the canal must be “dug through a saddle between steep hills”.
The Panama geology also was most prohibitive. Avalanche like mudslides occurred, and these slides grew worse as excavation progressed. The unfavorable geology meant that the angle for the sides of the canal could not be one to one or 45 degrees; the soil at Panama required a one on four slope. And, if the bottom canal breadth was 72 feet and waterline 90 feet, a canal 29-1/2 feet deep would require the final cut at some parts of the canal to be almost three-quarters of a mile across.
Building a canal with locks at Panama would be a colossal undertaking. A Panama Canal sans écluses would breach the boundaries of technology in the 19th century; it was a near impossibility. A more careful analysis of requirements and corresponding scope would have revealed the unfavorable Panama geology, a major hindrance to the possibility of project success.
Scope Gaps
Scope gaps are another drag on project cost and schedule. Gaps in scope arise from loose ends in requirements. The typical cause is committing to a project before completion of requirements. When missing requirements are discovered late in the project cycle, change happens; it’s unavoidable. Some of these scope gaps could legitimately result from the ingenuity of the project. Others from a lack of stakeholder participation in the requirements generation process. Some scope gap is expected; it difficult to be completely thorough. But many times scope gap occurs because of rushed analysis, which is needless.
Scope Creep
New insights and ideas emerge as the project progresses. The temptation from this new found knowledge is to assign additional requirements to the project in an attempt to improve the project deliverables. But this is a bad idea. It’s like moving the goal post when you are on the one yard line. Just because a change may improve the product does not mean it should necessarily be included. And many times these changes are inserted because the consequences are underestimated and not properly analyzed. Scope creep is a real threat to the achievement of the project. And a successful project many time does not require all the feasible product improvements.
Scope and Software & Hardware Problems
The more novel project the more susceptible to it is to defects. Software not working properly or as advertised is common. Project related hardware components may not work and have to be fixed. These risks become visible through sufficient analysis and planning.
Scope and Integration Defects
Components may work well, but when integrated to make a whole, system failure results. System or integration failures notoriously occur late in the project cycle, and near delivery. This limits a project manager’s flexibility and ability to compensate. They also are difficult to diagnose and correct. A thorough system analysis prior to integration may help support the early identification and management of integration problems.
Summary
Scope risk is a particular issue in the early stages of the project lifecycle. Study carefully the requirements and associated scope to avoid the impossible, and minimize scope gaps. Also make sure all stakeholders are included in scope development. New insights come as the project takes shape. But not all improvements contribute to the ultimate success of the project.
Consider carefully before introducing additional scope change to the project. Projects, and, particularly, inventive projects are susceptible to defects where components and/or systems do not operate as required. Defects may occur at the component level or system level. System level defects are particularly problematic because they generally occur near project delivery dates. System analysis may help prevent or alleviate defects, and support their management.
You may also want to consider the below references: