In one of my previous jobs, I was a part of a project that included a big, strategic initiative.  It included a purchase of a breakthrough manufacturing technology that didn’t exist on a commercial scale (yet).  Purchasing this technology would make my company a leader in that category, but time was of the essence and the team needed to act quickly.  The company that produced that technology had the capacity to manufacture only 3 units per year and we needed to get our hands on that piece of equipment fast.

Our R&D/engineering team studied specs, scoped locations where the technology was going to be installed, while our finance team drafted Appropriation Request and our Legal team drafted legal documents.

The business case was presented to the Leadership Committee as a big, strategic and time-sensitive initiative and within 5 weeks the team obtained approval to spend $XXMM.   All estimates were done at a high level, but we all agreed that assumptions were conservative and the contingency of 20% was added to the numbers.  We all felt good about the project.

The project started shortly after that. We made the payment, started building the piece of technology and then…..  new news arrived.  While we could manufacture new products (using this new technology)  ….our manufacturing plant didn’t have enough capacity to package this new product!  How did that happen?   Who was to blame?  How was that missed?  Was packaging capacity in or out of the scope?

The business lesson of defining (or not defining) the scope of the project was painful and very costly.  Underestimating project scope will always undervalue the cost.   It will change the profitability of the project or potentially, the ultimate decision of launching or not launching that product…

Changes to the project scope happen all the time but they might be costly and embarrassing.  While the author of  Scope Change Management: Keeping Projects on Track (http://www.technologyexecutivesclub.com/Articles/management/artScopeChangeManagement.php) emphasizes that  “controlling and managing scope change is critical to the success of any project, as scope changes can significantly impact the cost, schedule, risks and quality of the entire effort”  I think Project Managers must think holistically and strategically.  They must understand how their work fits into their company’s strategic objectives, how their project will impact other work components, departments and processes.  Understanding these elements is crucial to the Project Managers who would like to avoid scope changes and who would like to avoid embarrassment of partially or insufficiently defining a project scope.

According to authors of the article called:  FOUR TECHNIQUES FOR DEFINING PROJECT SCOPE  http://www.jamasoftware.com/wp-content/uploads/documents/wiegers-four-techniques-for-defining-project-scope.pdf  there are four steps in defining a successful project scope:

VISION AND SCOPE (Authors describe product vision and project scope as “Vision and Scope” defines Project “interfaces” with the rest of the world. )

USE CASE DIAGRAM (Visual illustration of interfaces between project and external world)

FEATURE LEVELS (Chart of users mapped to external entities)

SYSTEM EVENT (Describes features of the project)

Although the article was targeting more of a software implementation, I think these components are universal and serve as good guidance to help successful PMs define a winning Project Scope.

The scope, finances and the outcome of the project at (described above) would have been totally different if PM used these techniques.