Herb Krasner, University of Texas at Austin (ret.), CISQ Advisory Board member
A new Texas state law adds specific monitoring requirements for large IT projects in Texas state agencies. It requires regular monitoring and reporting on IT project performance indicators of: schedule, cost, scope, and quality. IT scope measurement is the focus of this new report.
Download it here: Scope Measurement on Large IT Projects in Texas: A Position Paper
IT scope metrics are used to define and deliver the right product or system to achieve an organization’s project goals and objectives. This paper recommends several specific IT scope metrics that should be used on all large IT projects:
- Balanced Scorecard (BAL)
- System/project size and its growth or change
- System requirements metrics for anomalies, quality, volatility, change impact and satisfaction
How these IT scope metrics are combined to answer the question of are we on track is discussed, along with typical scope challenges and next steps to properly implement the metrics.
For more information, read these related blog entries:
Dr. Bill Curtis, Executive Director, CISQ
During May 25-27 the sponsors of CISQ met in Bangalore, India to develop a specification for automating a Function Point-style measure for analyzing the productivity of maintenance and enhancement activity. Current Function Point-based measures do not account for significant portions of the code in a modern application, that is, the non-functional code required for operating large multi-language, multi-layer IT applications. Thus developers or maintenance staff can perform extensive work enhancing, modifying, and deleting code that does not affect traditional Function Point counts. Consequently their productivity cannot be accurately measured. Although NESMA has proposed an adjustment for this problem, the IT community needs an automatable solution that analyzes the full application.
The goal for this mew measure involves sizing the portion of an application affected during maintenance and enhancement activity in a way that is strongly related to the effort expended. The fundamental question related to this goal is how non-functional code should be measured when it is involved in changes. This spring several CISQ sponsors ran scripts on some of their applications to determine what portions of their code went unmeasured in traditional Function Point counting. In Bangalore they compared their results and discussed options for measuring the application code affected in maintenance activity. After two days of debate and discussion they coalesced on an approach which, after being formalized, will be submitted to the Object Management Group for consideration as a supported specification (an OMG standard).
Although the sponsors started from traditional methods for counting Function Points, they did not limit themselves to the constraints of these counting techniques. Thus, this specification might be more accurately thought of as Automated Implementation Points since it measures more than just the functional aspects of an application. This new measure will supplement traditional Function Point measures by providing a more complete sizing of the work performed during maintenance and enhancement. Thus this measure will enable more accurate analysis of productivity for use in benchmarking, estimating maintenance effort, and understanding the factors that cause variation in results. We will provide additional updates as the specification progresses.