Agile: The Good, the Bad and the Ugly

According to the Project Management Institute website, the PMI Agile Certified Practitioner (PMI-ACP) is their fastest growing certification.

In the Guide to the Project Management Body of Knowledge (PMBOK Guide), Agile methods are discussed under the Project Lifecycle definition as follows:

“Adaptive project life cycle, a project life cycle, also known as change-driven or agile methods, that is intended to facilitate change and require a high degree of ongoing stakeholder involvement. Adaptive life cycles are also iterative and incremental, but differ in that iterations are very rapid (usually 2-4 weeks in length) and are fixed in time and resources.”

The Agile concept grew out of collaboration between seventeen software developers around 2001. Their ideas evolved into the publication of the Manifesto for Agile Software Development, focusing on “delivering good products to customers by operating in an environment that does more than talk about “people as our most important asset” but actually “acts” as if people were the most important, and lose the word “asset”.”

According to our textbook, “The key point is that traditional PM techniques were developed to operate in the predictable zone where the scope of the project is fairly well defined and technology to be used is established. Agile lives in the unpredictable zone.” (Larson and Gray 584). Key differentiators of Agile include; continuous design, flexible scope, high uncertainty, and self-organizing teams engaged in high customer interaction.

Clearly Agile Project Management has reached the point of mainstream adoption. In our ever shifting, rapidly expanding world, think of the following types of projects which fall into the Agile sweet spot:

  • Where requirements will change drastically during the lifecycle.
  • The customer does not provide the specifics of what they want up front, but has a loose idea instead.

I spoke with a coworker, an experienced Product Manager, who feels that Agile is great in concept, but harder in implementation, especially in large organizations. The Agile model thrives on simplicity, which may be difficult to achieve in a big firm. Our employer is global, so a geographically distributed Engineering and Marketing group makes face-to-face meetings more difficult and prolongs the quick iterations that Agile strives for. Although, technology is helping to bridge the gaps.

Another topic of discussion surrounded total buy-in at the enterprise level. Agile is not something to dip your toes in. Success is realized and repeated through dedicated Agile teams. The Agile model does not necessarily align with a matrix team environment and may end up defeating the purpose due to a lack of team cohesion.

 

Questions / Discussion:

What are your thoughts on Agile Project Management? Good, bad, indifferent?

Feel free to share any personal experiences surrounding Agile, a shift away from Traditional PM or a hybrid approach.

Is it realistic to introduce Agile on a team-by-team basis? Do you see any roadblocks?

 

References:

http://www.pmi.org/certification/agile-management-acp.aspx

http://agilemanifesto.org/

Larson, Erik W. and Gray, Clifford F. (2011). Project Management: The Managerial Process. New    York, NY: McGraw-Hill Irwin.

“Cruising” with Project Management

Ok, so the title is corny but while on an Alaskan cruise last week I actually thought quite a bit about project management. What I’d like to do is share a few examples of what I saw and then ask for your thoughts on different ways project management enters into our daily lives but that we might completely miss.

This intricate dance begins the minute you check in online. Since there are approximately 2,300 passengers (this doesn’t include crew) who will be sailing, each person is given a 30 minute window during which they can arrive at the dock to board the boat. This really minimizes inefficiency of too many people arriving at once and having to stand in EXTREMELY long lines. See photo below. Once you check in your luggage is taken and put in a room that is organized by floor so that after everyone is on board and has checked in they deliver the luggage right to your room. You don’t have to deal with it or worry about it, it just shows up at your door!

Photo 1

Once we made it to our stateroom we started to look around outside and noticed the two pictures below.

Photo 2 Photo 3

This is a small sample of the food that they bring on board for every cruise and this really made me think about the Food and Beverage Director and how complicated it must be to provide food for 3,300 people (this includes the crew). There are SIXTEEN dining options on board but to help manage it two of the restaurants serve the exact same menu all week, one of the restaurants is a huge buffet serving the same meals all week and then you have a little variety from the other menus, but not many choices.

Lastly, one of the most efficient things they’ve done is to provide you one single card that acts as your room key and your bank card. AT check in you provide a credit card that they then link to your cruise pass and anytime you buy a drink, buy a meal or make a purchase at the duty free, they simply swipe your card and no real money exchanges hands. I also think this is a genius idea from a sales perspective because you really don’t feel like you’re spending money – its when you review your final bill before disembarking that you realize the money you’ve really spent!

I’m curious if others have examples of project management in their everyday lives (besides jobs) that they might overlook but that are truly pretty amazing, like the Davidson Glacier pictured below.

Davidson Glacier

Risky Business

 

This week in class we had to turn in our risk assignment for our fundraiser project.  As a financial analyst I work closely with risk on a daily basis.  Something we touched on in class when we created the risk was just the basics. What sort of risk, probability, value of the risk and contingency plan.  In reality, there is so much that goes into risk.  That it why I chose to research risk and see what else there is to know about risk.  I found a great article that talked about the fluidity of risk. The project management realm deals with an ever changing environment, which means risk is changing on an almost daily basis as well.  In my business, the programs I work on are very complex, which makes risk management and analysis complex as well and needs to be continuously re-visited and re-analyzed.

When creating our risk at my company, we don’t know how many out of box failures we may have on a program.  We don’t know how many parts might fail.  That is why over time, it is pivotal to continue to re-visit our risk.  Something I use in my job is called a “gating month”.  It is a month when we think our risk will be retired or OBE (overcome by events).   That being said, looking at risk on a daily basis is so important to monitoring project health.  As a project progresses and evolves, potentially so does the risk.

A personal example from my job as a financial analyst on government programs has to do with gating months.  For example, on my current program, we build and deliver hardware to the customer.  Because of that, a risk we carry has to do with our second sourced suppliers.  If a supplier who makes a part for our hardware build goes out of business or stops making the part, we need to be prepared for the costs that will go into replacing that part.  That includes finding another supplier, validating them and then potentially modifying the part to our specs.  This isn’t just a risk we carry throughout the entire program.  Over time, as we deliver hardware, this risk becomes smaller and smaller.  Why carry risk for 500 deliveries when we only have 50 left?  That is why, as a financial analyst, I work with the PMO to analyze our delivery schedule in relation to our risk items.  I help plan when this risk item should be reduced and when it will be OBE. When that happens the PMO needs to make an important decision.  Do we want to retire the risk to our bottom line or do we want to re-visit the program health and plan risk items for other problems that, over time, have now presented itself?

I have learned through personal experience, class and this article that risk is something that needs to be looked at continuously.  It needs to be managed daily and analyzed daily for any changes to the project and its environment.  It needs to be reduced or increased.  It needs just as much attention as the project execution itself.  In the article I read I found a great chart that shows the fluidity and cyclical nature of risk management and risk analysis:

 

Now a few questions on risk management and risk analysis:

1. Do you use risk at your job?  What sort of risk management and analysis do you perform?

2. Have you experienced a unique risk circumstance? What happened and what did you learn from the experience?

3. Do you have anymore insight and input into risk management and analysis?

4. Any other questions and comments are welcome!

 

http://www.pmoplanet.com/cross-discipline-elements/risk-management/

The Opportunity that fell through…

My second blog post originally touched on best practices of performance management, but after lecture this Saturday and an event that occurred with my team project, I thought it would be more interesting to touch on risk management. Professor Cook briefly touched on an important topic merely highlighted in the text and that is not discussed enough, opportunities, Chap 7 page 227. I never thought that an opportunity could be classified as a risk, until I experienced one.

My team/I have been working our networks to secure funds and increase awareness for the GCFD. Throughout our campaign, my networks have been extremely supportive of our mission and the GCFD. One connection, through a former DePaul teammate, seemed like a golden opportunity that I was definitely ready to exploit. Our team was connected with a food company that makes food items for large restaurant chains, as well as food service companies like Sysco. The company already had a connection with GCFD through monthly donations, but wanted to jump on board to support our campaign by donating as many pounds of food that we could take (share). I initially thought, “This opportunity is unreal! We’re going to blow our 9,000 pound goal out of the water.” After weeks of corresponding with our contact and GCFD (enhance) to donate the food items and confirm a pick up date (accept), the golden opportunity fell through the cracks. How did this golden opportunity turn into a risk? Everything was coordinated and clearly communicated, right? No. This turned out to not be the case.

The team was originally set to receive the entire 9,000 pounds. However, GCFD did not have the capacity to store the items because they were refrigerated/frozen items, as opposed to non-perishable items, which our campaign is based on collecting. A vast difference that I didn’t realize until after communication with both parties ensued, which in retrospect was scope creep on our own campaign. Our 9,000 pounds of food quickly dwindled down to 900 pounds, which was not the end of the world, but my spirit was a little crushed. We had already secured about 80% of our goal, and had a little over a week to finish strong.

The evening before the food item pick up was scheduled; I received a surprise email that our contact had worked hard to secure 4,000 pounds of food to donate on behalf our team to GCFD. I emailed GCFD to confirm, and the driver would be on site in the morning. The driver showed up the next day, and our contact emailed me, “The driver refused to take the food, what happened?” My immediate reaction was to follow up on my end to find the disconnect and fix it, ASAP. How could I fix this? Where was my contingency plan? I had none.

Once GCFD followed up, I learned that the food item storage dates were outside of the accepted time frame. I didn’t realize the risks associated with food item date ranges, and how this could impact receiving donations.

I don’t know if there is a way to make up for this missed opportunity, but I have definitely learned a lesson on practicing due diligence and realizing that opportunities can not only pose positive but also unassuming negative risks. The positive is that we were able to make a connection, and maybe someone else will be able to use this information for their team project. The negative is, we not only loss on an opportunity to make a large donation, but our credibility may have be compromised.

Has anyone experienced an opportunity that resulted in a risk/loss at either their company or within their teams? If so, how did you resolve and/or develop a contingency plan to counter the loss?

Knowing When You Need Help

Mary Hardiman

Lori Cook

MGT 598

 

“Property development: becoming your own project manager, or hiring in outside help?”

The article “Property development: becoming your own project manager, or hiring in outside help?” written by Paul Naybour brings important pointers to the surface. Companies must weigh the advantages and disadvantages of either assuming the responsibilities of a project manager themselves or hiring a project manager to assume those responsibilities. It is recurring question that requires thorough research and consideration before an answer can be reached.

Inf act, this was a question that was raised at my current workplace. My company had decided to create a new company offering to customers – the procurement of new plant construction (N.P.C.). Shortly after having started this new endeavor two years ago, my company realized that they may have bit off more than they could chew. They missed important project deadlines, underestimated the risk of the project, overestimated the budget of the project, etc. This resulted in a chaotic web of problems which were due to both a lack of time, experience and knowledge within our company. It was a struggle that the management team tried to juggle for nearly two years, but they realized that a change needed to be made in managing the N.P.C. project.

In the article, Naybour mentions a couple of factors to consider a company must decipher whether there is either the need or lack of need for a new Project Manager hire. First, the time frame of the project must be considered (“Property Development”). The project must be completed by a given deadline. The company must decide whether they can finish the project internally or if they need external help to finish the project. Second, the amount of the Project Manager’s experience must be considered (“Property Development”). If the project requires a considerable amount of knowledge/experience, the company must assess if they are qualified to complete the project. These are a couple of points to consider when deciding to use internal employees or find external candidates to complete the project.

My company assessed the situation and recognized the need for a new full-time Project Manager hire. Ideally, they wanted a manager with both nuclear project management and N.P.C. experience. However, the pool of candidates with both nuclear N.P.C. experience was very small. They were unable to find a candidate that met both of those requirements. Even if they had recruited a candidate that met those ideal requirements, this new hire most likely would have needed a high salary and fallen outside of my company’s budget. This was why they chose to hire a fairly recent undergraduate student with a degree in mechanical engineering. This new hire was new to the nuclear industry and new to the working world. My company decided to go this route to keep within their budget for the project. This was a thrifty alternative that allowed them to keep within their budget as well as fill the N.P.C. project holes that had previously existed. As discussed in class, this could be considered one of the Project Priority Matrix’s “tradeoffs” (“Defining the Project,” slide 10). My company decided to prioritize the need to meet their budget and fill the full-time position as the first priority while putting the experience/knowledge of the new hire as secondary. Nevertheless, the new hire added value to the N.P.C. endeavor and continues to gain the experience/knowledge at my company.

Works Cited

Cook, Lori. “Defining the Project.” MGT 598: Project Management. DePaul University, Chicago. 11 July 2015. Lecture.

Naybour, Paul. “Property Development: Becoming Your Own Project Manager, or Hiring in outside Help? Project Accelerator News.” Project Accelerator News. Project Accelerator News, 17 June 2015. Web. 11 July 2015.

Playing with Fire

Mitigating risk is an important part of business strategy – enough so that entire departments or teams are often devoted to risk management. Going through training session after training session, consultant after consultant, many managers understandably fear risk and uncertainty.

But for most early-stage startups, venture capitalists have much to teach about risk tolerance, and making the case for increasing exposure to risk. The Wall Street Journal notes that of 10 startups, three or four will fail completely, but another three or four will not return the original investment.[1] With the expectation that many startups will fail, venture capitalists have both a perceptive eye and a tough stomach to ensure that investments are carefully placed for long-term gain.

In a 2013 Forbes article, Steve Culp, of Accenture’s Finance and Risk Services, speaks to need to increase risk to stimulate innovation. Culp notes that “innovation and risk management seemingly do not naturally go hand-in-hand in many peoples’ minds,”[2] as he explores the silver lining to increasing risk in business. Culp speaks to two specific corporate structures that do a disservice to innovation. First, he cites the use of “stage gates” in selecting new projects. He notes that, “in many cases, the stage gating process is too focused on re-enforcing what the company does well today and the funnels end up producing only weak, incremental ideas that come to market slowly and lack emphasis on new areas for expansion.” Arguably, it’s not difficult to find companies that are aligned with this trajectory, making minimal gains to keep market share, rather than innovating. Culp also speaks to culture barriers in corporate settings, noting that, “another common impediment to innovation is an existing corporate culture that overly celebrates and rewards success.” With attention on metrics, sales goals, and other analytical focuses, it’s easy to lose sight of innovation when meeting benchmarks will suffice. Such cultures may even deter innovation, overtly focusing on guaranteed successes and lacking space for the possibility of failure.

Culp summarizes a “best practices” for innovation within corporate structure as three key elements: flexibility, speed, and control. He recommends that, “rather than placing all their bets on one or two experiments, companies may want to consider building a portfolio of early innovation investments that act as options.” Since “successful [innovations] often [require] speed, companies can use rapid experimentation and agile development to increase their chances of filling their innovation portfolios with new products and extensions.” Lastly, Culp notes “venture capital firms use controls, but these controls typically are designed to increase risk tolerance, fostering a culture that embraces the logic of intelligent mistakes.” By shifting the focus from risk avoidance to a safe space for innovation, companies of all sizes can benefit from playing with fire.

Have you seen innovative projects or suggestions stifled within your company, due to risk aversion?

What kinds of projects might be possible if your company had a higher tolerance for risk?

On a related note, Gever Tully beautifully sums up this tradeoff between risk and innovation in his humorous TED Talk: “5 Dangerous Things You Should Let Your Kids Do.”

[1] http://www.wsj.com/articles/SB10000872396390443720204578004980476429190

[2] http://www.forbes.com/sites/steveculp/2013/01/07/risk-management-can-stimulate-rather-than-deter-innovation/

[3] https://www.youtube.com/watch?v=C-VacaaN75o

Stop What You’re Doing. Read My Blog Post on Risk.

Over the course of my career, I have witnessed many projects.  I run sales for one of my company’s divisions.  If our sales group wins an application, it gets moved to program management/engineering group for execution.  The sales team is aware of the project, gets status, details, etc., but is not a true team member of the project.  Our sales group has a stake in the success of the project, because our customer won’t be willing to speak with me again if the project is a disaster.

So, all these projects have occurred, and I have had my fair share of disasters.  One very important piece of the program management pie is RISK.  Yes, risk identification and mitigation; what some may call the most boring part of a project.  The exclusion of this boring process has also led to me having very difficult conversations with customers.  So boring or not, stop what you are doing and make sure you go through risk identification/mitigation on your next project.  I don’t want to be yelled at anymore.  Help me, help you.

Here are some things that will help.

Know Thy Project – I have often seen projects go through risk identification and mitigation, only to get burned up on schedule and cost by an adjacent risk that nobody ever thought about.  This is due to rushing through project planning to start development.  BIG MISTAKE.  SIPOC is a great acronym to utilize at project onset.  It stands for Suppliers/Inputs/Process/Outputs/Customers.  It also helps with risk identification.  By utilizing SIPOC, the risk of not identifying risks is mitigated!  You’re welcome.  The following link explains SIPOC and how to utilize it: http://www.discover6sigma.org/post/2007/06/sipoc/.

Alright, great, we are now confident that risks have been fully identified because we looked at Risk through the SIPOC lens.  Now, it is important to have a Risk Register developed before beginning project execution.  Jumping the gun and moving to project tasks always seems to be the Achilles Heel of a project.  Risk Register’s avoid disaster.  There are many ways to develop risk register’s.  I found this link to have a good explanation and guide: http://hse.ie/eng/About/Who/OQR010_20090422_v_11Developing_and_populating_a_Risk_Register_BPG.pdf

The guide was based on health service industry, but the risk development process is solid; which would be expected considering the industry.  On page 5 and 6 of the above link, there is a really good visual for creating your project’s risk register.  The pages that follow provide guidelines for gathering risk and is similar to SIPOC.

Lastly, once a risk register is developed, and developed based on truly understanding risk, the most important thing to do is utilize the documentation.  I find it odd that project teams go through the risk process and then forget about it.  Bright hub had a nice article on managing risk throughout the project: http://www.brighthubpm.com/risk-management/45164-tips-on-managing-project-risk/

This article reminds PMs that risk registers should be reviewed with the team weekly.  This keeps the information that was so painstakingly developed right in front of the team.

Have you been involved in a project that utilizes these types of risk strategies?  Do you find that these strategies are effective, or, do you have alternate risk strategies that you feel are better?  Risk identification and reduction are often implemented, but overlooked later.  Why does this happen when risk processes are commonly employed at the beginning of a project?

Measuring In-Progress Project Performance

Measuring in-progress project performance is important so that potential problems can be identified as early as possible and so that stakeholders are made aware of progress. It is often a challenge to identify appropriate key performance indicators that actually measure what we really want to evaluate in regards to performance. Most people recommend choosing two to five KPI’s to properly gauge performance and to keep a high level view. It is important to remember that KPI’s are readings that enable stakeholders to assess how well the project is progressing in general against the stated objectives. It is often hard to measure the success of the project until long after the project has been completed.

Tracking the schedule and budget are critical KPI’s. However, it is important that these two are tracked together due to their tradeoff nature. Tracking discrepancies here allows the project manager to identify issues and drill down to resolve them quickly. More specific KPI’s, such as the number of scope changes and defects discovered during the project, can provide insight into the root causes of schedule and budget issues.

Another KPI to measure is the completion of quality deliverables. In order to effectively measure these, it is important that there is effective planning that clearly identifies critical tasks that need completed and what the specific requirements of each task are. Once these are identified and agreed upon, the project manager can track performance against these planned deliverables. These deliverables serve to link the required tasks to the schedule and give stakeholders an excellent pulse on project success.

The effort being expended by company resources is another important indicator. This can be very difficult to track and requires a disciplined approach. There are many types of technology that can assist with the tracking and reporting of time spent on a project by internal resources. Having this data can allow the project manager to track schedule compliance and better estimate completion dates. My company uses a software platform called Planview for all R&D projects.

Lastly, stakeholder satisfaction can be measured to assess how happy clients and team members are with the way in which the project is being managed and progressing. This data can speak to the responsiveness of the project team, the level of communication, the level of involvement, and the general feeling about the progress.

Combining these KPI’s and reporting them to stakeholders allows project managers to identify issues and deal with them proactively. Reporting these also allows the project manager to set expectations to stakeholders regarding the success of the project. What types of KPI’s have others used to track and report project performance?

Source: Pitagorsky, G. “Measuring In-Progress Project Performance.” Project Management Times. Project Management Times, 30 Jan. 2013.  Web. 18 Jul. 2015.

Is your organization prepared for a crisis?

Risk management can impact project budget, schedule, and/or quality. Business Blackout, Lloyd’s of London and the University of Cambridge’s Centre for Risk Studies, recently reported that U.S. power grid attack can result in approximately $70 billion in insurance claims and economic losses up as much as a trillion dollars.  Further, there are many different types of risk companies are trying to address including strategic, operational, compliance, financial, market, credit, and supply chain to name a few.  Strategic risk accounts for approximately 60% of the risk universe whereas operational and financial account for approximately 30% and 10%, respectively.

Even though many companies have been conducting risk assessment studies for many years, most companies find it challenging to create a complete enterprise risk assessment steps and realize its full value.  The chart below describes a basic process for risk assessment.

Risk Assessment

In the article, Enterprise Risk Management Beyond Theory, the study conducted interviews of five companies.  Most of the companies have suggested the following basic steps that are necessary for a robust risk assessment approach:

  1. Buy-in from the top: All the companies in the article agree that the leadership must believe in the risk assessment approach in order for everyone to cooperate.
  2. Keep it fresh: If the risk factors are not refreshed often, then breakdown may occur without having the key indicators triggering the events. The cyber attacks, which were considered unlikely a few years ago, are now considered an imminent threat to most large companies.
  3. Condense the information: A complicated checklist will confuse people and even oversee the basic risks. There are various ways to report information including showing a likelihood of an event (likely, unlikely, and certain), ranking of the likelihood of an event (1-5), or ‘heat map’.
  4. Learn from others: It is important to create processes that fit the organization’s need, but in order to gain a competitive advantage, the companies should also review other companies risk assessments.

My last employer used some of these approaches.  The company performed complete risk assessment every two-three years and the risk were categorized by business area or functions.  A formal “Risk Assessment Committee” reported directly to the President, which partly contributed to attention it received.  All aspects of the business were reviewed and the risks were categories 1-5 (5 being a likely scenario).  Anything over 3 were discussed each year and addressed over the following two years.  The checklist was kept transparent to all parties involved and certain part of the checklist was made available to the whole organization.

Certain risks such as business closure risks were discussed more frequently.  “Risk Assessment Checklist” was completed during and reviewed after each event (including weather-related events), which impacted a closure of the business.

What does your company or your competitors are doing to assess risk?  How do the factors mentioned above impact your organization?

 

Illustration of “Heat Map”

Heat Map

 

Source:

http://www.pwc.com/us/en/risk-management/assets/beyond-theory.pdf

http://www.pwc.com/en_us/us/issues/enterprise-risk-management/assets/risk_assessment_guide.pdf

https://www2.deloitte.com/content/dam/Deloitte/global/Documents/Governance-Risk-Compliance/dttl-grc-riskassessmentinpractice.pdf

http://www.insurancejournal.com/news/national/2015/07/08/374402.htm

Re-scope after scope?

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.