Print bookPrint book

Initiation, Success, and the Project Charter

Site: Saylor Academy
Course: BUS605: Strategic Project Management
Book: Initiation, Success, and the Project Charter
Printed by: Guest user
Date: Saturday, June 15, 2024, 10:02 PM

Description

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. 

Table of contents

The Work of Initiation

During initiation you will typically create the first draft of the following items, which take a high-level view of the project:

    • project charter: A "single, consolidated source of information" for project initiation and planning. It describes your current knowledge about the project and includes information such as the names of all stakeholders, a statement of your organization's needs, the history leading up to the project, the project's purpose, deliverables, and roles and responsibilities. A project charter is also sometimes called a project overview statement. It may be helpful to think of the project charter as a contract between the project team and the project sponsors.
    • scope statement: A document that defines the project's scope. Defining scope, which is really the heart of the initiation phase, is discussed in detail in the next section.
    • business case: An "argument, usually documented, that is intended to convince a decision maker to approve some kind of action. As a rule, a business case has to articulate a clear path to an attractive return on investment (ROI). At its simplest, a business case could be a spoken suggestion…. For more complex issues, a business case should be presented in a carefully constructed document. A business case document should examine benefits and risks involved with both taking the action and, conversely, not taking the action. The conclusion should be a compelling argument for implementation". A business case addresses these fundamental questions: 1) Why this project? 2) Why this project over another project? and 3) Why this project now?

Both the project charter and the scope statement typically evolve as the project unfolds and you learn more about the project details in the planning phase. This means that as you work through the initiation phase, you should always be thinking ahead to the following elements of the planning phase:

    • work breakdown structure (WBS): A description of the tasks associated with project deliverables, often in the form of a tree diagram. A work breakdown structure "displays the relationship of each task to the other tasks, to the whole and the end product (goal or objective). It shows the allocation of responsibility and identifies resources required and time available at each stage for project monitoring and management".
    • organizational breakdown structure (OBS): A description of the project team. It explains "who reports to whom, the details of the hierarchy, and the reporting structure…. Organizational breakdown structures are normally communicated visually through the use of graphs or charts. A project or general manager is listed and underneath the PM several divisions might be created, such as product development, design, materials management, and production".
    • work package: A "group of related tasks within a project. Because they look like projects themselves, they are often thought of as sub-projects within a larger project. Work packages are the smallest unit of work that a project can be broken down to when creating your Work Breakdown Structure (WBS)".
    • responsibility assignment matrix (RAM): A type of organizational breakdown structure in the form of a grid that typically lists project tasks in the first column and stakeholders across the top row, with tasks assigned to the various stakeholders. You can use it to determine if you have enough resources for a project, and to record who is responsible for what. RAMs come in several forms, but one of the most useful is a responsible, accountable, consult, and inform (RACI) chart, which designates each stakeholder's relationship to each task, using the following categories: responsible (actually does the work), accountable (has final authority over the activity), consulted (available to provide information about the activity), or informed (is informed after the activity is completed, often because his or her own work depends on it). (A RACI chart is sometimes also referred to as a linear responsibility chart).

Source: Board of Regents of the University of Wisconsin System, https://wisc.pb.unizin.org/technicalpm/chapter/project-initiation-scope-and-structure/
Creative Commons License This work is licensed under a Creative Commons Attribution 4.0 License.

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.

Creating the Project Charter

Developing the project charter is one of the most important parts of project initiation. By including all key stakeholders in the process of creating it, you will help ensure agreement on what constitutes project success, relevant constraints (e.g., time and budget), and the definition of scope.

The exact form of a project charter will vary from one organization to another. At some companies, the project charter is a spreadsheet file; in others, a document file. You'll find many templates for project charters available on the web. According to Managing Projects Large and Small: The Fundamental Skills for Delivering on Budget and on Time, a typical project charter contains some or all of the following:

    • Name of project's sponsor
    • Relationship between the project's goals and higher organizational goals
    • Benefits of the project to the organization
    • Expected time frame of the work
    • Concise description of project deliverables (objectives)
    • Budget, allocations, and resources available to the project team
    • Project manager's authority
    • Sponsor's signature

Above all else, a project charter should be clear and specific about the project's goals - that is, about the definition of success. The goals should be measurable, so there is no confusion about whether or not the project is a success:

Ambiguity on the goals can lead to misunderstandings, disappointment, and expensive rework. Consider this example of a broad-brush objective: "Develop a Web site that's capable of providing fast, accurate, cost-effective product information and fulfillment to our customers". That is how a sponsor might describe the project's objective in the charter. But what exactly does it mean? What is "fast"? How should accuracy be defined? Is one error in 1,000 transactions acceptable, or would one error in 10,000 meet the sponsor's expectations? To what degree must the site be cost effective? Each of those questions should be answered in consultation with the sponsor and key stakeholders.

But while you want to be specific about the project goals, take care not to dwell on the precise details regarding how you will achieve those goals:

A thoughtful charter indicates the ends but does not specify the means. The means should be left to the project manager, team leader, and members. Doing otherwise - that is, telling the team what it should do and how to do it - would undermine any benefit derived from having recruited a competent team.