Initiation, Success, and the Project Charter

Read this text. Be sure to note the importance of defining what success for the project looks like, as this will help shape the development of the project plan. The project sponsor and stakeholders are important in this process. 

Defining Success

Avoid the Mediocrity of Idea Averaging

As you embark on the systematic learning that is the hallmark of the initiation phase, you'll come across many ideas about the best way to achieve success. Some may be truly innovative, while others are slight variations on the same old thing. If innovation is your goal, then take care not to fall prey to idea averaging - taking a little from one idea, and a little from another, and a little from another - without fully committing to any. According to Andrew Hill, in a blog post on the topic, one way to avoid idea averaging "is to create a strong culture of feedback. Giving team members settings where they can point out flaws in current projects will help shift their mind into critical thinking mode. Feedback also gives you a tool to help measure, detect, or predict the failure of a project. In this way, the ideas you choose to act on are never set in stone, they are constantly being re-evaluated and rethought". You can read the complete blog post here: "How to Avoid Idea Averaging".

Experienced project managers know that you need to start fast by defining what "success" means for your project and determining how to measure it. To accomplish this, you need to talk with the individuals and organizations who will determine whether the project is a success. This may include internal or external clients, individuals or groups with approval authority, or groups of potential customers. Many projects flounder when the engineers responsible say, "We met our objective. We followed the plan as written" but the customer says, "You didn't provide what I wanted".

Countless products have been released and subsequently discontinued because the specifications did not match the customers' needs. One example is the 2013 release of Facebook Home, a user interface for the Android phone that turned Facebook into the user's home screen, removing the features, such as docks and app folders, that Android users love. How could the company make such a huge mistake? According to Business Insider, the Facebook Home development team, composed primarily of iPhone users, "was unfamiliar with the features that a normal Android user might get used to, and might not want to lose when they installed Facebook Home". This failure to learn about the customers' needs had disastrous results. The price of the HTC First, the phone on which Facebook Home came preinstalled, dropped from $99 to 99 cents within a few weeks. Ultimately, Time magazine named the HTC First one of the "lamest moments in tech" for 2013.

In the medical device industry, a successfully developed product might eventually be considered a failure if the development team underestimates the hurdles to achieving FDA certification. And we can look to self-driving cars for an example of how success extends beyond the narrower scope of product completion. Self-driving cars exist, but they have to be able to successfully interact with unpredictable human drivers and they need to have governmental approval in order to become a successful project.

In capital projects, the total cost of ownership (the total of direct and indirect costs related to the construction and use of a building) is crucial to determining whether or not a building is a success. For example, if a building designed for use only during the Olympics ends up being used for years afterwards, the building's maintenance costs will probably grow exponentially, transforming a supposedly successful building into a failure over the long term from the point of view of the host city. The key is realistically projecting the building's total design life. The cost of maintenance also plays a part in the question of whether construction funded by donors can be considered a success. In such cases, success is often defined as the facility's "grand opening" when it should really be defined as a fully funded operational infrastructure.

Successful project managers are typically very specific when they define project success. By contrast, new project managers make the mistake of being too general. However, being specific doesn't necessarily mean being long winded. By focusing on the end user's needs rather than on generating an exhaustive catalogue of physical requirements, you will provide a concise, useful definition of "success" for your project. By taking this approach, Lee Evey, the manager of the Pentagon rebuilding project after the 9/11 attack, was able to consolidate thousands of pages of specifications into "16 performance-based requirements. For example, his energy-efficiency requirement was that the building not use more than a specific number of BTUs [British Thermal Units] to heat and cool the building per year. It was then up to the design-build teams to meet the requirement within the budget".

Success in Lean and Agile

Traditional project managers tend to define success in terms of completing a project on time and within budget. But Lean presumes a more expansive definition of success - one that prioritizes eliminating waste and maximizing value, and in the process building customer loyalty that will extend to as-yet-unforeseen projects. The relentless focus on eliminating waste in the value stream has the corollary effect of keeping projects on schedule and within budget. It also tends to improve the quality of the final product, adding value that will actually benefit the customer.

In Agile development, a team agrees on its definition of intermediate success in the form of a sprint goal at every planning meeting. Success for the entire project is not measured in terms of being on time and on budget. Instead, in the spirit of the Agile manifesto, success means delivering "working software frequently" - software that the customer can actually use (Beedle et al. n.d.). Ultimately, success in Agile means delivering as much working software as the schedule and budget will allow.