logo for information-management-architect.com
Home
Strategy
Framework
Business Case Analysis
Project Planning
Requirements Analysis
Architecture & Design
Build Phase
Quality Assurance
Transition to Production
Management Information
Business Intelligence
Data Warehouse
Tools
Jobs
Contact David Bowman
leftimage for information-management-architect.com

Project Scope Management

Need project scope management for an information management project and want some practical suggestions to ensure rapid project delivery?

The objective of project scope management is to ensure that a projectProject Scope Management delivers everything that is “in scope” and does not deliver things that are “out of scope”.

Sounds easy--Just don’t build things that are out of scope!

We all wish it were that easy. Information management project teams are comprised of highly skilled individuals who frequently see things that they think should be improved. These well-intentioned “additions” can quickly add up in cost and time.

What do we need to manage scope?

The business case is the starting point. It lists project objectives and scope. Each objective should also identify a means of measurement.

Suppose one project objective is stated as “improve performance”, and a measurement is stated, as “ad-hoc report requests must be satisfied within 1 minute of submission instead of the current 5 minutes”.

The objective might be a little vague but we know how it’s going to be measured so we are OK.

What can go wrong?

Suppose we are loading the data mart, which will satisfy the ad-hoc request. We know the load will finish at 5:00 AM and that the users will never use it before 8:00 AM.  We also know it will return results within 1 minute.

Now imagine we have an innovative developer who decides to improve the load performance so that the load will finish at 1:00 AM. He develops temporary database structures, ETL routines and other code. Sure enough, the load does finish at 1:00 AM. Awesome!

Is this a good idea? Perhaps, but we need to look at the bigger picture.

The objective was to improve reporting performance and the code already did that—The extra code that was developed to improve load performance was not really needed.

It has introduced new routines that need to be maintained, new processes that need operational instructions, new data base structures that may need additional DBA support and new functionality that should be tested. (Which involves creating test cases, test data and test scripts).

The developers thinks they have an excellent solution but the project bears the cost of added scope. It does not take too many of these great ideas to add up to project delays.

How do we manage scope?

Project scope management is a key component of project management. The following items should be considered:
  • The business case needs to clearly state objectives;
  • Each objective must define a measurement that will ensure the objective has been achieved;
  • Each requirement needs to tie back to a business case objective;
  • Each requirement must specify acceptance criteria;
  • Upon approval of the requirements specification, no requirement should be changed without an approved change request—Even if it’s just a wording clarification;
  • Each requirement must be traced thru the architecture and design, development and test phase to ensure that:
    • A design specification satisfies the requirement; and
    • A test case specification tests the requirement.
That’s not too difficult, what else do we need?

Project scope management requires attention to detail. We know that we should not change requirements without an approved change request but what about other project documentation.

Once project documentation is approved, it should not be changed without an approved change request.
  • If a developer finds issues with a design specification, a change request is required before it can be updated. It may be a defect in the design specification or it may be a defect in the requirement—This can only be determined thru impact analysis.
  • If the design specification needs to be changed, then possibly a new integration test case and test data are required.
  • It we have a requirement defect, then perhaps we also need to change the quality assurance test cases and test data.
How do we ensure we don’t deliver more than what’s in scope?
  • A good requirements traceability process will help ensure that we delivery everything that was in scope;
  • A solid change management process should ensure we do not “add” things that increase scope; and
  • Strong technical management and good architecture and design reviews, will help ensure we do not deliver a lot of “nice to have” things that will increase scope.
Before you leave, remember…

Project scope management requires constant focus on project objectives, sound change management and strong technical management.

Treat any request for change, or ideas for improvement, as potential scope creep.
 


footer for Information management page