Project and Solution Scope – The Importance of Both!

Some big news in my life, I got married in July!   In the process of getting married and planning a wedding I found the analogy of the wedding process similar to project and solution scope.

Project Scope and Solution scope – How to explain the difference?
I will get to the PMI and IIBA definitions in a moment, but first I want to throw an analogy out there for everyone to react to.

For a little conceptual fun . . .
Engagement is to Project like Marriage is to Product/Solution

The wedding is the “go live” date and implementation of the marriage, the engagement is the temporary endeavor to create the marriage, the marriage is what lives on.

The marriage proposal is the project charter, likely talked and thought about for months, and finally funded with an engagement ring or other cultural token.  A commitment made by key stakeholders to create a marriage.
The planning begins . . . a budget is created for the wedding, negotiation between the couple and parents on budget, timeline, and scope of the wedding.  Meanwhile the couple begins planning their marriage, requirements of their lives together and visions of what the future will hold.  They work on planning the details of their finances, a home, children and family relationships, spirituality, lifestyle, etc. . . . Most discussed at a conceptual level before, but now they look at the details, it is reality now.   All features of a life together, some need to be ready for the wedding with high priority and some more conceptual and will evolve as time goes on.

A plan is created with all of the tasks needed, timelines, who is involved and budget.  Some parts of the plan are task driven and others are key activities to create the marriage.

A wedding coordinator is hired to manage the plan and make sure everything gets done.

Family gatherings are abundant to figure out design of the wedding, and in all of the heated discussion it is easy to lose sight that it is more important to plan the marriage than the wedding . . . so much focus on one day and yet we need to be focused on what lives on after that day.  The bride and groom try to find time among the chaos to discuss the details of their life together.

An hour-by-hour schedule is created for the wedding day and everyone has his or her part to play, including the rehearsal.

And . . . then there are the vows, the go-live!!!!

What lives on forever is the marriage . . . and just like a project, if requirements change, are missed, or the stakeholders, needs, and context changes the marriage is at risk.  The marriage must be adaptable and prove value to those impacted to be considered successful.

The Bride and Groom need to be BAs in their own right and ensure that they are thinking about the future and an enduring life together vs. being all consumed by the wedding.

The scope of the engagement and wedding is all of the tasks leading up to the wedding day to make the wedding happen.  I compare this to Project Scope.

The scope of the marriage is what lives on and the qualities, features, and capabilities that make it successful.  I compare this to Solution/Product scope.

Project Scope “The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.”
PMI PMBOK 4th Edition

Product Scope “The features and functions that characterize a product, service, or result.”
PMI PMBOK 4th Edition

Solution Scope “The set of capabilities a solution must deliver in order to meet a business need.”
IIBA BABOK v2

Some practicality of this for your projects:
– Documenting both the project scope and the product/solution scope is critical to the success and business value of the project. 
– PMs are typically responsible for the project scope
– BAs are typically responsible for the product/solution scope
– It is critical to success for BAs to define solution scope, even if it is not defined or well defined when you join the project.
– Solution/Product scope statements are the features and capabilities of the solution/product that live on after go-live; they are not the tasks that need to be done to deliver the solution.
– Project scope alone (task driven) is dangerous to the project success as there is no common alignment and documentation on what should live on once it is implemented.
– Use a Scope/Context Diagram to accompany a Solution/Project scope statement.  The IIBA newsletter had a great 5 part series on context modeling by By Meilir Page-Jones.  The series started in the Feb 2011 Newsletter. 

Happy solution scoping and happy marriage making!

Don’t forget to leave your comments below.