A Bucket of Scope

An architect relies on a clear understanding of scope.  In prior articles we have discussed the business context diagram, a great tool for establishing solution scope.  We also provided a technique for setting expectations regarding the scope of architecture activities.  In this article, I intend to expand on the importance of understanding (or establishing, if you are in a project lead role) the scope of a project.

Without a boundary confirming what is within the remit of a project and what is not, there is no way to:

  • focus effort on the right activities,
  • determine if the project has been successful, or
  • even know when a project is completed.

Without defining the scope of activities, you are really just spending money and goofing around.

The most economical way to identify project scope is with a series of iterative refinements.

  1. Very high level scope is identified at the project inception – a few bullets or a short paragraph should do the trick and provide enough information for an order of magnitude estimate to determine if you want to continue exploring the project.
  2. A system context or Use Case diagram can be a quick way to drive into a slightly more detailed, capability driven level of scope.  This is typically enough information to design a conceptual level architecture and, with a sprinkling of assumptions as required, a more precise cost estimate.
  3. Business requirement statements can be used to bring project scope to the next level of detail, leading to functional requirements and Use Cases as needed.

At each iteration, the project sponsor can make a decision as to whether more should be invested in the project based on the current understand of the expected cost.

And now… the bucket!

Sometimes project stakeholders have trouble understanding the importance of project scope, especially when it means they may not get everything they want.  I find a “bucket” to be a useful metaphor for discussion of scope with stakeholders:

  • Everything inside the bucket will be delivered by the project, and anything not in the bucket will not.
  • The bucket can only hold a finite number of items.
  • A larger bucket costs more in terms of money and time than a smaller bucket.
  • A larger bucket can hold more items, but is heavier and more difficult to handle and results in a bigger impact if dropped.
  • Once you determine what the project bucket contains, adding to the bucket requires removing something else from the bucket or upgrading to a larger bucket.

I have found that this bucket analogy can help transition a potentially emotional discussion of scope into a more mathematical discussion of feasibility.

In any event, I covered all the items I had in today’s bucket.  I intend to expand on the use of prioritization to manage your scope bucket in a future article!

 

Dan Hughes
Dan Hughes is a principal consultant and partner at Systems Flow, Inc., where he leads the technology services practice. He has 20 years of software engineering experience spanning a broad range of technologies and techniques. Startup to enterprise, he has launched, managed, and executed all aspects of both product and enterprise life cycle, delivering complex, enterprise-scale architectures for clients in the public and private sector, in industries ranging from banking and insurance to international development. Dan holds a Bachelor of Science in Computer and Systems Engineering from Rensselaer Polytechnic Institute. For more details, please visit Dan's LinkedIn profile
Dan Hughes

Latest posts by Dan Hughes (see all)



Comments

Got something to say?