Initiating Phase

In the initiating phase, you are recognizing the existence of a project and authorizing it to begin. Recall from the definition at the start of the chapter that a project has to have a start and finish and that it must be unique.

In the IT world, typically a project will begin with a customer request for a given system to be developed or some sort of infrastructure to be put into place—something like that. It is up to you, the project manager, to recognize a project when you see one.

Next, you take the steps that are necessary to validate the project's existence. Not all projects make it into the project mill just because someone feels they are worthy of the effort of requesting. It is the project manager who interviews the customers requesting the project, validates that there is a business need, and then formulates the project concept documentation. In a project concept document, you're clearly delineating what the project is and what it is not. You're not yet creating any project plans, schedules, deadlines, milestones, scope documents, or other materials. You're simply stating: "This is what the project is, and what the customer wants."

Only after you've defined what the project is, are you ready to go to the planning phase and define its scope—the work that you'll be doing.

When we deal with these phases, we talk about the inputs and outputs of a given phase. Inputs are things that go into a given phase that make it operational. Things happen during the phase that produce outputs, which the next phase can utilize. In the initiating phase, typically the input will be the customer request. Various sign-offs are obtained as documents are created. We' l l talk in more detail about these documents in later chapters.

An output from the initiating phase is the project charter, which authorizes the project to begin. The charter then becomes an input to the planning phase.

It' s not likely that you ' d label a tab in your project book as "Initiating." It' s more likely that you ' d label the tab "Requirements." The documentation that you create will be a requirements document (talked about in more detail in later chapters), which will detail what the customer wants—what the deliverables are.

Was this article helpful?

0 0

Post a comment