Defining Scope: It’s the Deliverables, Stupid!

After you’ve managed a few IT projects, you come to realize how important it is to define the scope and have the sponsor, steering committee, or other approvers agree to it before you try to develop a schedule or budget.  Sure, the project charter will describe the project at a high level, but in the absence of a detailed scope statement, stakeholders will invariably see what they want in the charter, despite the fact that you didn’t include it in your plans.  And in order to get to the level of detail you need to clearly identify what is in and out of scope, you need to think in terms of deliverables.

After you’ve assembled the business requirements, and the technical requirements, and the performance requirements, and information security requirements, and every other demand, constraint, expectation, preference, and request, take a moment to update your stakeholder register.  If you uncovered some previously undocumented stakeholders, or have some new insights into what stakeholder expectations (or influence) might be, update it now.  Also, take the time to document assumptions and constraints, before you get too far down the path – you’ll be glad you did, once you start conducting your risk analysis.

Now, create Post-It Notes for each deliverable your project would produce, if every requirement you uncovered was in scope.  Link every deliverable to one or more stakeholders, and if applicable, specific assumptions and constraints.  If you have a stakeholder receiving no deliverables, what is their stake?  And if you have a product with no stakeholder, why are you producing it?  Then consider the following questions for each deliverable:

  • At what point in the project will the stakeholder(s) receive this deliverable?
  • What criteria will they use to accept or reject it?
  • What other deliverables must be produced in order to produce this deliverable?
  • What business need, objective, or goal specified in the charter is supported by this deliverable?
  • What project constraints apply? What are the potential impacts of producing this deliverable?
  • Are the assumptions reasonable for this deliverable?

Draw a time scale on your white board, and then place the Post-It Notes along the time scale.  Use a marker to group deliverables linked to specific constraints or assumptions.  Are you seeing potential problems producing some deliverables?  If so, add them to the Risk Register.  Do you have multiple deliverables supporting the same business objective?  If so, are they all necessary?  Draw a box, labeled “Out of Scope,” and move the unnecessary Note to it.  Is there a deliverable with a lot of required inputs?  Are all of them really required?  Is the level of effort justified?  If not, move them out of scope.

If a particular stakeholder is going to receive a number of deliverables at the same time, will they be able to adequately review them?  Will your project team be able to deliver them?  Does it make more sense to eliminate some, or possibly deliver them over a longer period of time?  Note that you aren’t trying to nail down a schedule, just a logical sequence of events and a rough time scale.  Remember – time is nature’s way of keeping everything from happening at once.

Now, step back and take a look at the whole.  Consider the business objectives, budget, and dates specified in the charter.  Is all of this reasonable, give the time, money, and resources available?  If not, start looking for the least beneficial deliverable, from the standpoint of the business objectives in the charter, and move it Out of Scope.  Also move any deliverables no longer needed as a result of that decision, and adjust your time scale.  Repeat, until what is left is the group of deliverables that produce the most business value, according to the objectives specified in the charter.

The final step is to capture which deliverables are in and out of scope in a document that can be approved by your sponsor and steering committee.  Expect some disputes and negotiation, but once they sign off on it, you have a baseline for integrated change management, as well as the beginning of a work breakdown structure.  Your Post-It Notes and timeline also give you a basis on which to begin developing a schedule, and a starting point for qualitative risk analysis.  It’s even useful for managing stakeholder and project team expectations, and planning communication events.  After all, when it comes to your project, it’s the deliverables that matter – to everyone!

This entry was posted in Scope Management by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.