Project Planning

Plans are nothing; planning is everything

You have now gained more knowledge about your project. Working on the SOW helped you refine a number of aspects of your project. You should now start project planning, which involves:

• Detailing the project’s requirements.
• Detailing the activities that make up your project – you will use the Work Breakdown Structure (WBS) to accomplish this.
• Creating a network diagram to determine the dependencies among the activities.
• Identifying the resources (people, equipment, facilities, etc.) you need for the project.
• Establishing a schedule for your project and refining its scope.
• Putting all of the information into a project management plan that will become the baseline document for your project.

Tip: Remember to get the plan approved by the main stakeholders of the project.

“Projects happen in two ways: a) Planned and then executed or b) Executed, stopped, planned and then executed ” - Unknown author

Requirements

Before working in your project, you should determine and analyze your customer’s requirements to be able to define and estimate the needed effort and resources to execute the project. And accordingly to correctly plan for the project’s deadline. Clear and concise requirements help a lot in this exercise. The next steps forward depend a lot on the requirements. They start with the WBS (Work Breakdown Structure).

WBS

To begin the project planning process, start working on the WBS, which is an effective tool that helps you list all the tasks involved in your project. The WBS allows you to group all the tasks under main activities ensuring that you have a clear overview of what you need to execute during the project.

Tip: Careful with the level of detail in your WBS, 3 levels is good; 5 the limit, and 7 becomes unwieldy.

A good way of developing your project’s WBS is by using the major milestones/deliverables that you identified in your SOW. Once the milestones have been identified, brainstorm with your project team to detail the tasks that you must accomplish in order to achieve the milestones. It is advisable to break-up the work into manageable “chunks” (maximum work activity duration of 5-10 man-days, or 40-80 man-hours).
If you and your team are familiar with the project, a milestone approach will work very well. If this is not the case, then consider including in your workshops someone who may not be on your project team but has previously completed a similar project.

“Running a project without a WBS is like going to a strange land without a roadmap” - J. Phillips

Here is a simplified WBS for the design of a website:

For more complex projects with a higher level of detail, you can choose the following format for your WBS:

Project Estimation

The three pillars for the success of any project are cost, effort and quality. The foundation of these pillars is based on estimation technique used for the project. However, historically it has been observed that lots of projects experience cost, effort and schedule overrun or poor quality. In most of cases, the project end up taking alternate paths to fulfill the budget constraint and ends up delivering an inadequate product/application/service.

Tip: A project’s estimate is an estimate; it is never the real value of the project. Though a good estimate should approach the actual value of the project after completion.

Before proceeding in the planning activities, you should estimate your project’s activities and tasks. Based on the WBS you created, you should start estimating the effort each task/activity will take regardless of the resources needed for the task. The project estimation exercise depends on the following factors:

• Project requirements
• Usage of correct estimation techniques
• Historical data for similar tasks/projects
• Experience of the people working on the estimation exercise

These factors control the accuracy of the estimate, so always try to have them on place.

Effort Estimation

Effort estimation is the process of predicting the most realistic use of effort required to develop or maintain software based on incomplete, uncertain and/or noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds.

Typically, effort estimates are over-optimistic and there is a strong over-confidence in their accuracy. The mean effort overrun seems to be about 30% and not decreasing over time. However, the measurement of estimation error is not unproblematic. The strong over-confidence in the accuracy of the effort estimates is illustrated by the finding that, on average, if a software professional is 90% confident or “almost sure” to include the actual effort in a minimum-maximum interval, the observed frequency of including the actual effort is only 60-70%.

Effort Estimation Approaches

There are many ways of categorizing estimation approaches. The top level categories are the following:

• Expert estimation: The quantification step, the step where the estimate is produced based on judgmental processes.
• Formal estimation model: The quantification step is based on mechanical processes, e.g. the use of a formula derived from historical data.
• Combination-based estimation: The quantification step is based on a judgmental or mechanical combination of estimates from different sources.

Below are examples of estimation approaches within each category:

Estimation Approach	Category	Examples of support of implementation of estimation approach
Analogy-based estimation	Formal estimation model	ANGEL
WBS-based (bottom up) estimation	Expert estimation	MS Project, company specific activity templates
Parametric models	Formal estimation model	COCOMO[1], SLIM[2], SEER-SEM
Size-based estimation models	Formal estimation model	Function Point Analysis, Use Case Analysis, Story points-based estimation in Agile software development
Group estimation	Expert estimation	Planning poker, Wideband Delphi
Mechanical combination	Combination-based estimation	Average of an analogy-based and a Work breakdown structure-based effort estimate
Judgmental combination	Combination-based estimation	Expert judgment based on estimates from a parametric model and group estimation

---

[1] Constructive Cost Model - Boehm - 1981

[2] Software Lifecycle Management - Putnam - 1979

Selection of Estimation Approach

The evidence on differences in estimation accuracy of different estimation approaches and models suggest that there is no “best approach” and that the relative accuracy of one approach or model in comparison to another depends strongly on the context. This implies that different organizations benefit from different estimation approaches. Findings that may support the selection of estimation approach based on the expected accuracy of an approach include:

• Expert estimation is on average at least as accurate as model-based effort estimation. In particular, situations with unstable relationships and information of high importance not included in the model may suggest use of expert estimation. This assumes, of course, that experts with relevant experience are available.
• Formal estimation models not tailored to a particular organization’s own context, may be very inaccurate. Use of own historical data is consequently crucial if one cannot be sure that the estimation model’s core relationships (e.g., formula parameters) are based on similar project contexts.
• Formal estimation models may be particularly useful in situations where the model is tailored to the organization’s context (either through use of own historical data or that the model is derived from similar projects and contexts), and/or it is likely that the experts’ estimates will be subject to a strong degree of wishful thinking.The most robust finding, in many forecasting domains, is that combination of estimates from independent sources, preferable applying different approaches, will on average improve the estimation accuracy.

In addition, other factors such as ease of understanding and communicating the results of an approach, ease of use of an approach, cost of introduction of an approach should be considered in a selection process.

WBS-Based Technique

The estimate, depending on the nature of the project, should consider/include the following for each item in the WBS:

• Requirements Activities
  • Requirements gathering
  • Requirements analysis & use cases
  • Requirements documentation
  • Requirements review
  • Prototype
  • Requirements review with customer
  • Requirements signoff
• Design Activities
  • System design
  • UI design
  • Database design
  • Design documentation
  • Design review
• Development Activities
  • UI development
  • System development
  • Integration
  • Unit testing
• Testing Activities
  • Test cases
  • Functional testing
  • Integration testing
  • Security testing
  • Performance & stress testing
• Rework Activities
  • Bug fixing
  • Re-testing
  • Regression test
• User guides & help documentation
• Packaging & Deployment
• Demos
• Estimation
• Planning
• UAT (User Acceptance Test)
• Users training preparation
• Users Training
• Re-estimation
• Re-planning
• Travelling/Transportation
• Ramp up/Training
• Environment setup
• Hidden efforts for
  • Communication
  • Resource allocation
  • Team management
  • Project tracking
  • Project management
• Risks
  • Determined risks
  • Undetermined risks/Contingency

Tip: It is useful to conduct the estimation with the project team to have each members input and to consider all opinions.

Estimating Task Time

There are several ways to estimate the effort of a task, one of which is a formula that combines the optimistic time, the pessimistic time, and the most like time into a weighted average. The formula is:

The PM or project scheduler estimates the optimistic, most likely, and pessimistic durations and plugs them into the formula. For example, optimistic duration = 10 days, most likely duration = 12 days, and pessimistic duration = 17 days.

Expected Time = (10 + (4*12) + 17)/6 = 12.5 days

The formula (in this example, 12.5 days) becomes the starting point for further adjustment such as adding more time for contingency purposes or reducing time due to acquiring additional resources.

How else can a PM deliver tasks or projects on schedule? By decomposing tasks into small work packages that can have their progress measured by the day, week, or month. Being alerted that task delays have occurred within a day or two of when they are supposed to be completed (which is possible when tasks durations are short) greatly assists the PM in developing corrective action plans required for task schedule recovery.

Yes, project estimates are sometimes guesses. Being able to make an educated, consistent estimate using one of these methods, combined with your common sense, will set you apart from your peers.

Size-Based Technique

This estimation technique involves selecting one or two completed projects that most closely match the characteristics of your planned project. The chosen project(s), or analogues, are then used as the base for your new estimate by comparing the size of the feature to one another and to the other completed project. The size is then transformed to effort based on certain equations defined per company standards. A feature may have for example a small, medium or large size, and a comparative methodology is used to determine the size of each feature, then the sizes are summed up and then converted to effort. The sizing estimation is a high level and easy way to determine the project’s estimate and can be very helpful in the very early stages of the project, though the detailed estimation process is still needed.

Psychological Issues Related to Effort Estimation

There are many psychological factors potentially explaining the strong tendency towards over-optimistic effort estimates that need to be dealt with to increase accuracy of effort estimates. These factors are essential even when using formal estimation models, because much of the input to these models is judgment-based. Factors that have been demonstrated to be important are: Wishful thinking[3], anchoring[4], planning fallacy[5] and cognitive dissonance[6].

• It's easy to estimate what you know
• It's hard to estimate what you know you don't know
• It's very hard to estimate things that you don't know you don't know

---

[3] Wishful thinking is the formation of beliefs and making decisions according to what might be pleasing to imagine instead of by appealing to evidence, rationality or reality.

[4] Anchoring or focalism is a cognitive bias that describes the common human tendency to rely too heavily, or "anchor," on one trait or piece of information when making decisions.

[5] Planning fallacy is the tendency to underestimate task-completion times.

[6] Cognitive dissonance is an uncomfortable feeling caused by holding conflicting ideas simultaneously.

Difference between Effort & Duration

Many times our clients ask us “How much time do you need to complete this task?”

Typically the development teams respond by saying “It will take 12 hours to complete it” or “It will be completed in 12 hours”.

The above two sentences have two completely different meanings.

“It will take 12 hours to complete it” refers to an effort of 12 hours required to complete the work.

“It will be completed in 12 hours” refers to the duration within which the task will be completed.

Having said that, lets understand the difference between the terms “Effort” and “Duration”.

Effort refers to the number of person days or person hours required to complete a task. e.g. 12 hours of effort: This means if one person worked on this task nonstop, they can complete the task in 12 hours.

Duration refers to the time period required to complete the task. e.g. 12 hours duration: This means the task will be completed in 12 hours’ time. i.e. This statement does not say how many people will be working on it. It could be 3 people working for 8 hours of effort each and getting it ready within 12 hours duration. It could also be that one person will be working on it for 3 hours of effort, but will have time to complete it only in 12 hours’ time.

In order to get out of this confusion, we have set certain guidelines to be used by our teams whenever interacting with clients on topics of effort and duration.

While giving a proposal/estimate, we always give two numbers:

• Estimated Effort
• Estimated Duration

Also when replying to any client queries on when a task will be ready, we give them two data points: one about effort and the other about duration.

Tip: Estimates should always be performed based on the effort. Plans should always be performed based on the duration.

Cost Estimation

The cost of the project is often fixed before the design is done, and sometimes even before design has begun. Estimation now becomes more of guesswork based upon experience that was gained by screwing up earlier estimates. Without the design, it was quite impossible to know how many lines of code/functions/components/objects would be required. The estimator should rely on data and documents available before one starts the design, such as the functional and non-functional requirements, workflows, and use-cases. Therefore, requirements gathering and analysis is very critical to the project's estimation (design, development, and testing).

The cost of the project is determined based on the effort estimation, in addition to the needed resources cost, e.g. computers, printers, transportation cost… which are considered as direct cost on the project. Other indirect costs should also be included in the definition of the man/day price, examples of indirect costs are: electricity, non-core functions salaries, water, taxes…

Some organizations define rates for each resource depending on his role and his salary scale, and other organizations just have a fixed price for the man/day. In all cases, there should be a risk factor included in the cost estimation.

Contracting Types

There are many ways to price a contract, the most common being Firm Fixed Price and T&M. Selecting the right contract type for your project shouldn’t be a big deal; each one has its own advantages and disadvantages. The Project Manager should have a firm understanding and working knowledge of the various contract types and how their use may affect project outcomes.

• Firm Fixed Price (FFP): The fee to provide the product or services is quoted and fixed for the duration of the contract. FFP contract shifts the project risks to the Provider, who is responsible for cost, performance and profit or loss. The Buyer pays a fixed fee and does not need to know what the Provider is actually spending on the project.
• Time and Materials (T&M): The fee is quoted as an hourly rate plus the cost of materials, supplies, or travel expenses. The T&M contract is used when the Buyer wants full control over the project. Provider profits are factored into the hourly rate and the Buyer is billed for the hours worked.
• Cost Plus: There are actually several variations of Cost Plus, they include: Cost Plus Incentive Fee (CPIF), Cost Plus Fixed Fee (CPFF), and Cost Plus Percentage of Cost (CPPC). Each of these covers the Provider’s costs and an additional fee that is calculated in various ways in an attempt to limit the Buyers costs. A major distinction between CP and FFP or T&M contracts is that with CP contracts, the Provider costs are disclosed to the Buyer for reimbursement.
• T&M with Not to Exceed (NTE): This is a variation of the FFP contract where the Buyers try to get the best potential price while capping total fee paid to the Provider. NTE contracts are usually an attempt by the Buyer to benefit if the project finishes early, and limit exposure if the project runs long.

Tip: Establish a level of signing authority for the project’s budget. If you have to get multiple approvals for spending money, you will waste a lot of time thus impacting your ability to get your project done on time.

There is always business risk with any contract. The business risk can have a positive or negative impact to contract depending on many factors that affect the outcome of the project. From the Buyer perspective, cash is important and cash flow is to be protected. From the Provider perspective, cost control is important to prevent loss of profits. Selecting the appropriate contract type can limit project costs by shifting cost risks or other constraints to the other party.

The project manager, however, may not always be able to choose the contract type and should try to understand the business needs of the clients or customers. All project managers must learn to manage the risks for their respective parties and to be honest about scope, quality, resources, and scheduling.

Responsible project managers will approach project risks in a logical and methodical manner. The project manager should select an appropriate contract type that protects their interests in the contract and limits their risks. Throughout the project, the project manager should aggressively defend the project scope and prevent scope creep using all available tools. Some of those tools include scope control and change management procedures.

Network Diagrams

The WBS allowed you to identify groups of activities that you need to accomplish in your project. However, the WBS does not show the dependencies or sequence between these activities. A network diagram will allow you to illustrate this. Once your network diagram is ready, only then can you realistically start determining your project’s schedule.

A Network Diagram is a visual representation of a project’s schedule. Well known complements to network diagrams include the PERT[7] and Gantt[8] charts. A network diagram in project management is useful for planning and tracking the project from beginning to finish. It represents a project’s critical path as well as the scope for the project.

A good network diagram will be a clear and concise graphic representation of a project.

There are two types of network diagrams: The Arrow Diagram and the Precedence diagram. The arrow diagram depicts nodes for events and arrows for activities. The precedence diagram depicts activities in the order they occur. If you work in IT you will most likely use the arrow diagram. 

‘A’ and ‘B’ each represents an event node. These event nodes refer to an instant when an activity is started or completed. An event node occurs only when all activities entering the node have been completed. The arrow represents the activity that takes place during the event. For example, if a task in a project were “research competition’s ad campaign,” then the event nodes would designate the start and finish of this activity whereas the arrow would designate the activity itself.

Using the arrow and node method, you can depict project dependencies. In the diagram, you see that Event C depends upon activities from Events A and B to be completed, and Event D depends upon Event C’s activities to be completed.

Dotted lines with arrows represent “dummy arrows.” Rather than depict a dependency between two items, these arrows depict a logical relationship. Dummy arrows have no duration. They do not depict an activity. Instead, they transfer logic from one event node to another.

Once the project is mapped out, you can write a key for the visual representation, listing the duration of events and activities. The network diagram will provide you and your project team with a full visual representation of your project.

---

[7] Program Evaluation Review Technique, a methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program. A similar methodology, the Critical Path Method (CPM) was developed for project management in the private sector at about the same time.

[8] A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt, an American engineer and social scientist. Frequently used in project management, a Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track specific tasks in a project.

PERT Chart

A PERT chart presents a graphic illustration of a project as a network diagram consisting of numbered nodes (either circles or rectangles) representing events, or milestones in the project linked by labeled vectors (directional lines) representing tasks in the project. The direction of the arrows on the lines indicates the sequence of tasks. In the diagram, for example, the tasks between nodes 1, 2, 4, 8, and 10 must be completed in sequence. These are called dependent or serial tasks. The tasks between nodes 1 and 2, and nodes 1 and 3 are not dependent on the completion of one to start the other and can be undertaken simultaneously. These tasks are called parallel or concurrent tasks. Tasks that must be completed in sequence but that don't require resources or completion time are considered to have event dependency. These are represented by dotted lines with arrows and are called dummy activities. For example, the dashed arrow linking nodes 6 and 9 indicates that the system must be configured before the user test can take place, but that the resources and time required to prepare for the user test (writing the user guides and user training) are on another path. Numbers on the opposite sides of the vectors indicate the time allotted for the task.

The PERT chart is sometimes preferred over the Gantt Chart, another popular project management charting method, because it clearly illustrates task dependencies. On the other hand, the PERT chart can be much more difficult to interpret, especially on complex projects. Frequently, project managers use both techniques.

Gantt Chart

A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt, an American engineer and social scientist. Frequently used in project management, a Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track specific tasks in a project.

Gantt charts may be simple versions created on graph paper or more complex automated versions created using project management applications such as Microsoft Project or Excel.

A Gantt chart is constructed with a horizontal axis representing the total time span of the project, broken down into increments (for example, days, weeks, or months) and a vertical axis representing the tasks that make up the project (for example, if the project is outfitting your computer with new software, the major tasks involved might be: conduct research, choose software, install software). Horizontal bars of varying lengths represent the sequences, timing, and time span for each task. Using the same example, you would put "conduct research" at the top of the vertical axis and draw a bar on the graph that represents the amount of time you expect to spend on the research, and then enter the other tasks below the first one and representative bars at the points in time when you expect to undertake them. The bar spans may overlap, as, for example, you may conduct research and choose software during the same time span. As the project progresses, secondary bars, arrowheads, or darkened bars may be added to indicate completed tasks, or the portions of tasks that have been completed. A vertical line is used to represent the report date.

Gantt charts give a clear illustration of project status, but one problem with them is that they don't indicate task dependencies - you cannot tell how one task falling behind schedule affects other tasks. The PERT chart, another popular project management charting method, is designed to do this. Automated Gantt charts store more information about tasks, such as the individuals assigned to specific tasks, and notes about the procedures. They also offer the benefit of being easy to change, which is helpful. Charts may be adjusted frequently to reflect the actual status of project tasks as, almost inevitably, they diverge from the original plan.

You have now learned how to flesh out the activities involved in a project, determine the sequence of the activities, and establish a schedule. You are now ready for the next step – determining the resources that you need to accomplish your project activities. Note that once you have determined the resources and their availability, you may need to review your project schedule (Gantt chart).

Critical Path Method (CPM)

Definition

Critical Path is the sequence of activities that must be completed on schedule for the entire project to be completed on schedule. This is the longest duration path through the work plan. The duration of the critical path determines the duration of the entire project. Each task/activity on the critical path is called a critical task. If a critical task is delayed by one day, then entire project will be delayed by one day (unless another critical task can be accelerated by one day).

The critical path may change from time to time as activities are completed ahead of or behind schedule. There may be more than one critical path depending on durations and work flow logic.

A related concept is the critical chain, which adds resource dependencies.

The Critical Path Method (CPM) is one of several related techniques for doing project planning. CPM is for projects that are made up of a number of individual "activities." If some of the activities require other activities to finish before they can start, then the project becomes a complex web of activities.

Critical Path Analysis is an effective and powerful method of assessing:

• What tasks must be carried out
• Where parallel activity can be performed
• The shortest time in which you can complete a project
• Resources needed to execute a project
• The sequence of activities, scheduling and timings involved
• Task priorities
• The most efficient way of shortening time on urgent projects
• How long your complex project will take to complete
• Which activities are "critical," meaning that they have to be done on time or else the whole project will take longer

If you put in information about the cost of each activity, and how much it costs to speed up each activity, CPM can help you figure out:

• whether you should try to speed up the project, and, if so,
• what is the least costly way to speed up the project.

An effective Critical Path Analysis can make the difference between success and failure on complex projects. It can be very useful for assessing the importance of problems faced during the implementation of the plan.

PERT is a variant of Critical Path Analysis that takes a more skeptical view of the time needed to complete each project stage.

Activities

An activity is a specific task. It gets something done. An activity can have these properties:

• names of any other activities that have to be completed before this one can start
• a projected normal time duration

If you want to do a speedup cost analysis, you also have to know these things about each activity:

• a cost to complete
• a shorter time to complete on a crash basis
• the higher cost of completing it on a crash basis

CPM analysis starts after you have figured out all the individual activities in your project.

Getting & Estimating Resources

Now that you have a better overview of the activities and schedule of your project, you have to determine the resources that you will need to execute the activities. You will need resources such as people, material and other supplies. For example, in a website design project you would typically need graphical designers and programmers, access to rooms to hold your meetings, software, computers, and so on.

People

Let’s begin with the most important resource – people. You will need to determine the skills required for accomplishing the activities of your project. After this phase, you need to match people to those skills. A good way to do this is to create a skills sheet that matches skills to activities. Also keep columns for the name of people, their start dates, their cost and the training they need to accomplish their tasks – this information can sometimes be obtained at the same time. Here is an example of a sheet that you can use to accomplish this:

WBS	Activity	Skills Needed	Name of Person	Skills Level	Deliverable	Effort Days	Start Date	End Date	Cost
2.1	Write marketing content	Marketing	JJC	Expert	Marketing content for website	10	May 07	May 20	9,500
2.2	Write HR content	HR	AFH	Intermediate	HR content for website	8	May 10	May 30	7,600
2.3	Edit all content	Document editing	KDM	Expert	Edited content for website	5	Apr 04	Apr 20	4,000

The above table goes beyond simply matching activities and skills – it also contains columns for the names of the people who will execute an activity, their skills level, the deliverable that they are expected to produce, the date on which they can start and finish, and their cost. Fill in these columns as soon as you can. Often the managers of the people that you need will be able to commit the availability of these people for your project. However, it is recommended that you always cross-check this information with your project team members, and pay particular attention to the following:

• Check up the availability of your project team members by taking into account their vacations, sick days and the other projects that they are already working on.
• Ask the functional managers of your project team members to assess the skill set of their people, and the effort days that will be required by them to accomplish the activities assigned to them (always cross-check the effort days with the person who will executing an activity).
• The functional managers should be able to tell you how much their people cost. The more detail you go into when estimating the costs, the more accurate your cost estimates will be. So be detailed when it comes to costs as this frequently becomes an issue later on in the project.

Nonperson Resources

You may also need to factor in the availability of nonperson resources such as supplies, equipment and facilities. To do this, create a nonperson availability sheet similar to the example below:

WBS	Activity	Resource Needed	Time in Hours	Date(s) Needed
4.1	Design brochure	- Computer - Color Printer	80	04 to 29 Apr
4.2	Brochure review meeting	- Meeting room with computer connected to projector	3	04 May
4.3	Make copies of draft brochure	- Color Photocopier	2	05 May

Now that you have an idea of your resource requirements and their availability, go back to your Gantt chart. You might need to re-adjust it in order to take into account your team members’ or other nonperson resources’ availability.