Scope Creep and Action Reports (SCARs) in Software Projects

  Lessons Learned   Scope Management   Knowledge Shelf  

Abstract
In information technology software development projects (after submitting the initial requirements), a customer is very likely to change and keep changing the requirements—much to the annoyance of the development team. A team writing software is also often negligent in creating the proper documentation or following a coding standard. This article discusses the scope creep that may sneak into software projects and why the creation of project documentation should be made mandatory, whether the project methodology is agile, waterfall, or any other.

Introduction
Jim Davis, a project manager, just started working on a new software development project that’s very similar to the project his team completed last year. A month after submitting the requirements, the customer is now busy adding more changes to the original requirements and expanding the scope of project. To recall how his team dealt with this kind of scope creep, Jim wants to look into the lessons learned document from last year’s project, but he cannot remember where it is. The team’s technical lead left the company and none of the other team members have any idea about what Jim is asking about. Though Jim remembers some of the pitfalls his team had in the last project, he shudders to think that the team has to go through the same route again. A lessons learned document would have …

Please log in or sign up below to read the rest of the article.