After the project has been defined and the project team has been appointed, you are ready to enter the second phase in the project management life cycle: the detailed project planning phase.
Project planning is the heart of the project life cycle, and tells everyone involved where you’re going and how you’re going to get there. The planning phase is where the project plans are documented, the project deliverables and requirements defined, and the project schedule created. It involves creating a set of plans to help guide your team through the execution and closure phases of the project. The plans created during this phase will help you to manage time, cost, quality, change, risk and related issues. It will also help you manage staff and external suppliers, to ensure that you deliver the project on time and within schedule.
The project planning phase is often the most challenging phase for a project manager, as you need to make an educated guess of the staff, resources and equipment needed to complete your project. You may also need to plan your communications and procurement activities, as well as contract any 3rd party suppliers.
The purpose of the project planning phase is:
Establish business requirements.
Establish cost, schedule, list of deliverables and delivery dates.
Establish resource plan.
Get management approval and proceed to the next phase.
The basic processes of the project planning are:
Scope planning specifies the in-scope requirements for the project and facilitates creating the work breakdown structure.
Preparing the work breakdown structure specifies the breakdown of the project into tasks and sub tasks.
Project schedule development specifies the entire schedule of the activities detailing their sequence of execution.
Resource planning specifies who will do what work at which time of the project and if any special skills are needed to accomplish the project tasks.
Budget planning specifies the budgeted cost to be incurred in the completion of the project.
Procurement planning focuses on dealing with vendors outside of your company
Risk management planning charts the risks, contingency plan and mitigation strategies.
Quality planning for quality assurance to be applied to the project.
Communication planning on the communication strategy with all project stakeholders.
The planning phase refines the project’s objectives gathered during the initiation phase and plans the steps necessary to meet those objectives by further identifying the specific activities and resources required to complete the project. Now that these objectives have been recognized, they must be clearly articulated entailing an in-depth scrutiny of the recognized objective. With such scrutiny, our understanding of the objective will change. Often the very act of trying to describe something precisely gives us a better understanding of what we are looking at. This articulation serves as the basis for the development of requirements. What this means is that after an objective has been clearly articulated (clearly stated) we can go about the business of stipulating in concrete terms what we have to do to achieve it. Obviously, if we do a poor job of articulating the objective, our requirements will be misdirected and the resulting project will not represent the true need.
Users will often begin describing their objectives in qualitative language. The project manager must work with the user to provide quantifiable definitions to those qualitative terms. These quantifiable criteria include: schedule, cost, and quality measures. In the case of project objectives, these elements are used as measurements to determine project satisfaction and successful completion. Subjective evaluations can be removed with actual numbers.
A web user may ask for a fast system. The quantitative example would be all screens must load in under 3 seconds. Describing the time limit in which the screen must load is specific and tangible. For that reason, you’ll know that the requirement has been completed when the objective has been met.
Let’s say your company is going to produce a run of holiday eggnog. Your objective statement might be stated this way: Christmas Cheer, Inc. will produce two million cases of holiday eggnog to be shipped to our distributors by October 30 at a total cost of $1.5 million or less. The objective criteria in this statement are clearly stated and fulfillment of the project objective can be easily measured. Stakeholders will know the objective is met when the two million cases are produced and shipped by the due date within the budget stated.
When articulating the project objectives you should follow the SMART rule:
Specific (get into the details). Objectives should be specific and written in clear, concise, and understandable terms.
Measurable (use qualitative language so you know when you are finished). A requirement must have a measurable outcome; otherwise you will not be able to determine when you have delivered it.
Acceptable (to stakeholders).
Realistic (in terms of achievement). Objectives that are impossible to accomplish are not realistic and not attainable. Objectives must be centered in reality.
Time bound (deadlines not durations). Objectives should have a timeframe with an end date assigned to them.
If you follow these principles, you’ll be certain that your objectives meet the quantifiable criteria needed to measure success.
You always want to know exactly what work has to be done to finish your project BEFORE you start it. You’ve got a collection of team members, and you need to know exactly what they’re going to do to build your product or meet the project’s objectives. The scope planning process if the very first thing you do to manage your scope. Project scope planning is concerned with defining all of the work of the project and only the work needed to successfully meet the project objectives. The whole idea here is that when you start the project, you need to have a clear picture of all the work that needs to happen on your project, and as the project progresses, you need to keep that scope up to date and written down in the project’s scope management plan.
You already got a head start on refining the project’s objectives in quantifiable terms, but now you need to go a lot further and write down all of the deliverables that you and your team are going to produce over the course of the project. Deliverables include everything that you and your team produce for the project; anything that your project will deliver. The deliverables for your project include all of the products or services that you and your team are performing for the client, customer, or sponsor. But deliverables include more than that. They also include every single document, plan, schedule, budget, blueprint, and anything else that gets made along the way; including all of the project management documents you put together. Project deliverables are measurable outcomes, measurable results, or specific items that must be produced to consider the project or project phase completed. Deliverables like objectives must be specific and verifiable.
All deliverables must be described in enough detail so that they can be differentiated from related deliverables. For example:
A twin engine plane versus a single engine plane.
A red marker versus a green marker.
A daily report versus a weekly report.
A departmental solution versus an enterprise solution.
One of the project manager’s primary functions is to accurately document the deliverables and requirements of the project and then manage the project so that they are produced according to the agreed upon criteria. Deliverables describe the components of the goals and objectives in a quantifiable way. Requirements are the specifications of the deliverables.
After all the deliverables are identified, the project manager needs to discover and document all of the requirements of the project (Figure 28). Requirements describe the characteristics of the deliverable. They may also describe functionality that the deliverable must have or specific conditions the deliverable must meet in order to satisfy the objective of the project. A requirement is an objective that must be met. The project requirements defined in the scope plan describe what a project is supposed to accomplish and how the project is supposed to be created and implemented. Requirements answer the following questions regarding the AS IS and TO BE states of the business: who, what where, when, how much, how does a business process work.
Requirements may include things like dimensions, ease of use, color, specific ingredients, and so on. If we go back to the example of the company producing holiday eggnog; one of the major deliverables is the cartons that hold the eggnog. The requirements for that deliverable may include carton design, photographs that will appear on the carton, color choices, etc.
Requirements specify what the project deliverable should look like and what it should do. They can be divided into six basic categories, functional, non-functional, technical, user, business, and regulatory requirements.
Functional requirements describe the characteristics of the deliverable, what emerges from the project in ordinary non-technical language. They should be understandable to the customers, and the customers should play a direct role in their development. Functional requirements are what you want the deliverable to do.
If you were buying vehicles for a business your functional requirement might be; the vehicle should be able to take a load from a warehouse to a shop.
For a computer system you may define what the system is to do; the system should store all details of a customer’s order.
The important point to note is that WHAT is wanted is specified, and not HOW it will be delivered.
Non-functional requirements specify criteria that can be used to judge the product or service that your project delivers. They are restrictions or constraints to be placed on the deliverable and how to build it. Their purpose is to restrict the number of solutions that will meet a set of requirements. Using the vehicle example (Example 15); without any constraints, the functional requirement of a vehicle to take a load from a warehouse to a shop, the solutions being offered might result in anything from a large truck to a sports car! Non-functional requirements can be split into two types: performance and development.
To restrict the types of solutions you might include these performance constraints:
It must take a load of at least one ton.
The load area must be covered.
The load area must have a height of at least 10 feet.
Similarly, for the computer system example (Example 16), you might specify values for the generic types of performance constraints:
The response time for information to appear to a user.
The number of hours a system should be available.
The number of records a system should be able to hold.
The capacity for growth of the system.
The length of time a record should be held for auditing purposes.
For the customer records example these might be:
The system should be available from 9 AM to 5 PM Monday to Friday.
The system should be able to hold 100,000 customer records initially.
The system should be able to add 10,000 records a year for 10 years.
A record should be fully available on the system for at least 7 years.
The important point with these examples is that they restrict the number of solution options that are offered to you by the developer. In addition to the performance constraints you may include some development constraints.
There are three general types of development constraints:
Time: When a deliverable should be delivered
Resource: How much money is available to develop the deliverable
Quality: Any standards that are used to develop the deliverable, and develop methods, etc.
Technical requirements emerge from the functional requirements, they answer the question, and how will the problem be solved this time; will it be solved technologically and/or procedurally. They answer how the system needs to be designed and implemented to provide required functionality and fulfill required operational characteristics. For example, in a software project, the functional requirements may stipulate that a data base system will be developed to allow access to financial data through a remote terminal; the corresponding technical requirements would spell out the architecture of the data structure, the language in which the database management system will be written, the hardware on which the system will run, telecommunication protocols that should be used and so forth.
User requirements are what the users need to do with the system or product. They focus on the experience users need to have with the system, they can also reflect how the product will be designed, and define how test cases must be formulated.
Business requirements are the needs of the sponsoring organization, always from a management perspective. Business requirements are statements of the business rationale for the project. They are usually expressed in broad outcomes the business requires, rather than specific functions the system may perform. These requirements grow out of the vision for the product that, in turn, is driven by mission (or business) goals and objectives.
Regulatory requirements can be internal or external and are usually non-negotiable. They are the restrictions, licenses and laws applicable to a product or business, imposed by the government.
Automated teller machines (ATMs) can be used to illustrate a wide range of requirements (Figure 29). What are some of the physical features of these machines, and what kinds of functions do they perform for users? Why did banks put these systems in place? What high level business requirements did they have in mind?
The following represents one possible example of each type of requirement as they would be applied to a bank’s external ATM.
ATM function requirement: The system shall provide users with the ability to select whether or not to produce a hardcopy transaction receipt before completing a transaction.
ATM non-functional requirement: All displays shall be in white 14 pt Arial text on black background.
ATM user requirement: The system shall complete a standard withdrawal from a personal account, from login to cash, in less than two minutes for a first time user.
ATM business requirement: By providing superior service to our retail customers, Monumental Bank’s ATM network will allow us to increase associated service fee revenue by 10% annually on an ongoing basis, using a baseline of December 2008.
ATM regulatory requirement: All ATMs shall connect to standard utility power sources within their civic jurisdiction, and be supplied with uninterruptible power source approved by said company.
The effective specification of requirements is one of the most challenging undertakings project managers face. Inadequately specified requirements will guarantee poor project results.
Documenting requirements is much more than just the process of writing down the requirements as the user sees them; it should cover not only what decisions have been made but also why they have been made. Understanding the reasoning that used to arrive at a decision is critical in avoiding repetition. For example, if a particular feature has been excluded because it is simply not feasible, that fact needs to be recorded. If it is not, then the project risks wasted work and repetition when a stakeholder requests the feature be reinstated during development or testing. Once the requirements are documented, have the stakeholders sign off on their requirements as a confirmation of what they desire.
While the project manager is responsible for making certain the requirements are documented, it does not mean the project manager must perform this task. The project manager can enlist the help of stakeholders, business analysts, requirement analysts, business process owners, and other team members to conduct the interviews and document the requirements. The project manager then reviews the requirements and incorporates them into the project documentation and project plan.
Now that we have the deliverables and requirements well defined, the process of breaking down the work of the project via a work breakdown structure begins. The work breakdown structure (WBS) defines the scope of the project and breaks the work down into components that can be scheduled and estimated and easily monitored and controlled. The idea behind the work breakdown schedule is simple. You subdivide a complicated task into smaller tasks, until you reach a level that cannot be further subdivided. Anyone familiar with the arrangements of folders and files in a computer memory, or who has researched their ancestral family free, should be familiar with this idea. You stop breaking down the work when you reach a low enough level to perform an estimate of the desired accuracy. At that point, it is usually easier to estimate how long the small task will take and how much it will cost to perform than it would have been to estimate these factors at the higher levels. Each descending level of the WBS represents an increased level of detailed definition of the project work.
As an example, if I want to clean a room, I might begin by picking up clothes, toys, and other things that have been dropped on the floor. I could use a vacuum cleaner to get dirt out of the carpet. I might take down the curtains and take them to the cleaners, then dust the furniture. All of these tasks are subtasks performed to clean the room. As for vacuuming the room, I might have to get the vacuum cleaner out of the closet, connect the hose, empty the bag, and put the machine back in the closet. These are smaller tasks to be performed in accomplishing the subtask called vacuuming. The diagram in Figure 30 shows how this might be portrayed in WBS format.
It is very important to note that we do not worry about the sequence in which the work is performed or any dependencies between them when we do a WBS. That will be worked out when we develop the schedule. For example, under 3.0 Vacuum (in Figure 30), it would be obvious that 3.3 Vacuum carpet would be performed after 3.4 Connect hose and plug! However, you will probably find yourself thinking sequentially, as it seems to be human nature to do so. The main idea of creating a WBS is to capture all of the tasks, irrespective of their order. So if you find yourself and other members of your team thinking sequentially, don’t be too concerned, but don’t get hung up on trying to diagram the sequence or you will slow down the process of task identification.
A WBS can be structured any way it makes sense to you and your project. In practice, the chart structure is used quite often (as in the example in Figure 30) but it can be composed in outline form as well (Figure 31).
You’ll notice that each element at each level of the WBS (in either Figure 30 or Figure 31) is assigned a unique identifier. This unique identifier is typically a number, and it’s used to sum and track costs, schedules, and resources associated with WBS elements. These numbers are usually associated with the corporation’s chart of accounts, which is used to track costs by category. Collectively, these numeric identifiers are known as the code of accounts.
There are also many ways you can organize the WBS. For example, it can be organized by either deliverable or phase. The major deliverables of the project are used as the first level in the WBS. For example, if you are doing a multimedia project the deliverables might include producing a book, CD and a DVD (Figure 32).