Impact of any change in the final schedule date

A product development cycle can be fairly chaotic. When you hold a finished product in your hands or have it installed in your machine, the product would look great and you would not even think about the intense passion and drama that is part of the process involved in bringing out such a release. Most teams start out with a concept that this cycle of the product release will be simple, and have a lower amount of tension in the ongoing release. However, it has been my experience that a large number of such releases can be incredibly full of tension; you enjoy bringing out a product that is liked and purchased by a large number of users all over the world, but the times when you are working on the product cycle can be enjoying and frustrating at times.
One of the most tension filled times is the last week and last days of the schedule; you are this close to making the release date, you wonder whether there is anything that was forgotten; you pray to whoever you hold dear and holy that there are no major defects that come up in the last few days of the release cycle that can have an impact on the quality or the schedule of the release. In most cases, changing the release date of the product is next to impossible given the number of items that get shaken up. What happens when you have to change the release date:
- All media communication is screwed and it can end up as a PR disaster worrying people about the quality of the product
- There is a huge impact of the confidence of the senior management in the team management especially when this schedule release impact comes up suddenly
- There is a revenue impact, since as part of finance sheets, there would already have been a calculation of the revenue that will come; any change in this date will cause some shortage in the revenue sheet. If this is a major product, it could actually spiral all the way to change in earnings of the organization.
- There are many processes that are already set in motion such as DVD production, retail channels, and delivery to other partners, and all of these are impacted. For example, if your product is planned to be loaded as part of the installed software on OEM's such as the desktop or laptops of HP, Sony, Dell, etc, there will be hell to pay. These partners have finely tuned schedules and it will take some major negotiation for these schedules to be reset.
- The team would already be high-strung because it is near the end of the cycle. They are expecting a period of down and low tension for some time after the release, and if the release is delayed, this can cause morale issues within the team and continued tension.
- If you are using partners and vendors along with the core team, any delay of the schedule will also need more time for these teams. For example, vendors who provide language translation and review services can be pretty expensive, and any schedule delays will need to factor these in.

As a result of these reasons, and more like them, the team always needs to be on the ball. It would be real bad management and estimation if something happens in the last few weeks to cause the schedule to be changed. There can always be legitimate reasons for a schedule to get changed, but these should be known well in advance so that preparations for all the reasons listed out above can take place.

What is Earned Value Analysis (EVA) in Project Scheduling?

Earned Value Analysis(EVA) provides a quantitative indication of progress. The project manager uses this method to track the project. Proponents of the earned value system claim that it works for every software project irrespective of the kind of work. As a part of this, there is an initial estimation of the total number of hours of doing this project, with every task being given an earned value which is based on its estimated percentage of the total effort. In simpler terms, a project manager will be able to determine, through a quantitative analysis, how much of the project is actually complete.

As a part of this process, the following steps are needed to be done:
- The BCWS (Budgeted Cost of Work Schedule) is evaluated for each task that is included in the project. This estimation is done in terms of person-hours or person-days(if the effort is much more than a few hours). So, for a given work task its BCWS is the effort.
- All the BCWS that are calculated for all the tasks are summed up to get a value called BAC(Budgeted Completion).
- The next variable BCWP(Budgeted Cost of Work Performed) is calculated. The method to calculate BCWP is by taking BCWS value for all the tasks that have been completed(at any point in the schedule).

In simple terms, the difference between BCWS and the BCWP is that BCWS is the estimate for all task that was supposed to be done, while BCWP is the summary of all the activities that were completed.

EVA compares the planned amount of work with what has actually been completed, to determine if cost, schedule, and work accomplished are progressing as planned. Work is earned or credited as it is completed.

Earned Value Analysis
- compares like terms and is quick to apply in practice.
- requires the ongoing measurement of the actual work done.
- tasks that have not been started or that have been completed are relatively easy to quantify in terms of earned value.

Project Scheduling - Different ways for tracking the schedule.

A proper project schedule is very important for a successful project delivery. The project schedule is a road map for a software project manager. A project schedule needs to be properly developed. A proper project schedule defines the tasks and milestones that are tracked and controlled as project proceeds. This tracking needs to be accomplished nicely and there are different methods and ways to do so...

- Timely project meetings regarding the status of the project are held and it should be ensured that each team member should report the progress achieved and the problems that are faced.
- There are different reviews that are conducted throughout the software engineering process. It becomes necessary to evaluate the results of all these reviews in order to accomplish proper tracking.
- To accomplish proper tracking, for each task of the project, the actual start date and the planned start date should be compared.
- To accomplish tracking, one should determine whether the formal project milestones are achieved by the scheduled date.
- To accomplish tracking, progress should be assessed quantitatively.

The best indication of progress is the completion and successful review of a defined software work product.
The control administers the project resources, cope with problems and direct the project staff. Control is light if the project is on schedule and within budget. The control is exercised to reconcile the problems if they occur.

In case the problem is identified and diagnosed:
- staff is redeployed
- additional resources should be focused on problem area.

A severe deadline can be managed by time-boxing technique. It chooses an incremental software paradigm and a schedule is derived for each incremental delivery. This technique is done when the product may not be deliverable by a pre-defined deadline.

Software Project Scheduling - Timeline Charts

What is a timeline chart ? Well, a project timeline is created to display the various activities of a project on a chart, in such a way that it depicts the tasks of the projects, the duration of the tasks, the sequencing of these, and the major milestones of the project. A Gantt chart is a typical software timeline chart, and the most popular one that most people tasked with preparing such a chart are aware of.

In timeline charts, a series of events are arranged on a bar graph. These charts are like user items. Each event can be a single point in time or a date range. A timeline chart enables the planner (and other stakeholders) to determine the set of tasks that will need to happen at a given point of time. The effort, duration and start date are inputs for each task. These tasks can be assigned to specific individuals. With these inputs, mapped on a chart, the timeline chart is developed. It is also called Gantt chart and it can be developed for the entire project. When the Gantt chart was first developed, it was a revolutionary construct in the field of project management.

The format of a timeline chart depicts the part of software project schedules that emphasize the concept scoping task for the product on which work is happening. All work tasks are located on the left hand column. The duration of each task is indicated by the horizontal bars. The diamonds indicate the task concurrency which indicates when multiple bars occur at the same time.

Project tables are tabular listing of all project tasks. Project tables are produced when all the information which is necessary for the generation of timeline charts are obtained. These project tables consists of all project tasks, its start and end date and the related information.

How to define a task set for a software project?

The process model is defined by a set of tasks which enables the software team to define, develop and support computer software irrespective of whether the software team uses an incremental model, linear sequential method, an evolutionary model. Nearly every project will have a different task set which means that no single task is appropriate for all projects.

The set of tasks that a simple project uses or needs is different from the set of tasks that is needed by a large complex system. A collection of task sets should be defined to meet the needs of different types of projects by the software process that is effective.

The task set that is developed should be distributed on a project time line. Task set depends on the type of the project and the rigor with which the software team decides to do the work. Different kind of projects encountered by software organizations are:

- Application enhancement projects
- Content development projects
- New application development projects
- Application maintenance projects
- Re-engineering projects

The factors that affect the choice of the task set for a single project type are:
- project size.
- number of potential users.
- critical nature of mission.
- longevity of the application.
- requirements stability.
- maturity of applicable technology.
- embedded and non-embedded characteristics.
- performance constraints.
- project staff.
- re-engineering factors.

For example, in concept development projects, major tasks followed are:
- Concept scoping
- Preliminary concept planning
- Technology risk assessment
- Concept proof
- Implementation concept
- Customer reaction

Project Scheduling - Relationship between people and effort

For a small project, requirements analysis, performing design, code generation and test conduction can be done by a single person but as the size of the project increases, more people get added. Adding people later in the project often has a disruptive effect on the project causing schedules to slip even further. If more people are added to a late project, be sure that you have assigned them work that is highly compartmentalized.

The people who are added later in the project should know the system properly. In addition to the time that it takes to learn the system, it also increases the number and complexity of communication paths. Every communication path requires additional effort and time.

Project schedules are elastic. It is possible to compress or extend a desired project completion date to some extent. If delivery can be delayed, the PNR curve indicates that project costs can be reduced substantially. As the project deadline becomes tighter and tighter, you reach a point at which the work cannot be completed on schedule, regardless of the number of people doing the work. The reality should be faced and a new delivery date should be defined.

Effort should also be distributed across the software process workflow. Recommended effort distribution is referred as 40-20-40 rule. Front end analysis and design and back end testing are allocated 40% of all effort while 20% of effort is allocated to coding. The characteristics of each project must dictate the distribution of effort. Requirement analysis may comprise 10-25 percent of project effort. Effort on analysis or prototyping should increase in direct proportion with project size and complexity.

What is project scheduling? What are the basic principles of project scheduling?

Software project scheduling is an activity that distributes the estimated effort across the project duration that is planned by allocating the effort to specific software engineering tasks. There are two perspectives of scheduling for software engineering projects:
- End date for release of computer based system has already been established. The organization is constrained to distribute effort within the time frame.
- Rough chronological bounds are discussed but end date is set by software engineering organization.

The basic principles that guide software project scheduling are:
While developing a schedule, compartmentalize the work, note task inter-dependencies, allocate effort and time to each task, define responsibilities, outcomes and milestones. Each of these principles is applied as project schedule evolves.

- Compartmentalize the project into number of manageable activities, tasks and actions. Both product and process are decomposed.
- Inter-dependency among various activities, tasks and actions should be determined. Some tasks can occur in sequence and some in parallel.
- Time frame should be allocated to each task. Task should be assigned a start and end date and whether the work is done on a full time or part time basis.
- Effort estimation is allocating number of people on software team. Project manager should ensure that no more than the allocated number of people are scheduled at any given time.
- Responsibilities should be defined for every team member.
- Outcomes should be defined for every task that is scheduled.
- Milestones should be defined for every task or group of tasks.

Concept of Project Scheduling - What is the root cause for late delivery of software?

After all the important elements are defined for a project, it is now time to connect all the elements. It means a network of all engineering tasks is created that will enable you to get the job on time. The responsibility for each task is assigned to make sure that it is done and adapt the network. The software project managers does this at the project level and on an individual level, software engineers themselves.

Project scheduling is important because there are many tasks running in parallel in a complex system and the result of each task performed has a very important effect on the work that is performed by other task. These inter-dependencies are very difficult to understand without project scheduling.

The basic reasons why software is delivered late are:
- Unrealistic deadline by someone outside the software group.
- Changing the requirements of customer and not reflecting them in schedule change.
- Underestimate of amount of effort and number of resources required for the job.
- Non considerable predictable or unpredictable risks.
- Technical difficulties that are left unseen.
- Human difficulties that are left unseen.
- Lack of communication or mis-communication among project staff.
- Project management is not able to judge that project is falling behind schedule.

The estimation and scheduling techniques when implemented under constraint of defined deadline gives the best estimate and if this best estimate indicates that the deadline is unrealistic, the project manager should be careful from undue pressure.

If the management demands that the deadline is unrealistic then following steps should be done:
- A detailed estimate is made and and estimated effort and duration is evaluated.
- Develop a software engineering strategy using incremental process model.
- Explain to the customer the reasons why the deadline is unrealistic.
- An incremental development strategy is explained and offered as an alternative.

Critical Path Method (CPM)

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.

CPM provides the following benefits:
* Provides a graphical view of the project.
* Predicts the time required to complete the project.
* Shows which activities are critical to maintaining the schedule and which are not.
CPM models the activities and events of a project as a network. Activities are depicted as nodes on the network and events that signify the beginning or ending of activities are depicted as arcs or lines between the nodes.

STEPS IN CPM PROJECT PLANNING:
1. Specify the individual activities : From the work breakdown structure, a listing can be made of all the activities in the project. This listing can be used as the basis for adding sequence and duration information in later steps.
2. Determine the sequence of those activities : Some activities are dependent on the completion of others. A listing of the immediate predecessors of each activity is useful for constructing the CPM network diagram.
3. Draw a network diagram : Once the activities and their sequencing have been defined, the CPM diagram can be drawn. CPM originally was developed as an activity on node (AON) network, but some project planners prefer to specify the activities on the arcs.
4. Estimate the completion time for each activity : The time required to complete each activity can be estimated using past experience or the estimates of knowledgeable persons. CPM is a deterministic model that does not take into account variation in the completion time, so only one number is used for an activity's time estimate.
5. Identify the critical path : The critical path can be identified by determining the following four parameters for each activity:
* ES - earliest start time.
* EF - earliest finish time.
* LF - latest finish time.
* LS - latest start time.
6. Update the CPM diagram as the project progresses : As the project progresses, the actual task completion times will be known and the network diagram can be updated to include this information. A new critical path may emerge, and structural changes may be made in the network if project requirements change.

CPM LIMITATIONS :
CPM was developed for complex but fairly routine projects with minimal uncertainty in the project completion times. For less routine projects there is more uncertainty in the completion times, and this uncertainty limits the usefulness of the deterministic CPM model.

Program Evaluation and Review Technique (PERT)

Complex projects require a series of activities, some of which must be performed sequentially and others that can be performed in parallel with other activities. This collection of series and parallel tasks can be modeled as a network. The Program Evaluation and Review Technique (PERT) is a network model that allows for randomness in activity completion times.
In a project, an activity is a task that must be performed and an event is a milestone marking the completion of one or more activities. Before an activity can begin, all of its predecessor activities must be completed. Project network models represent activities and milestones by arcs and nodes. PERT originally was an activity on arc network, in which the activities are represented on the lines and milestones on the nodes. Over time, some people began to use PERT as an activity on node network. For this discussion, we will use the original form of activity on arc.

PERT planning involves the following steps:
1. Identify the specific activities and milestones : The activities are the tasks required to complete the project. The milestones are the events marking the beginning and end of one or more activities. It is helpful to list the tasks in a table that in later steps can be expanded to include information on sequence and duration.
2. Determine the proper sequence of the activities : This step may be combined with the activity identification step since the activity sequence is evident for some tasks. Other tasks may require more analysis to determine the exact order in which they must be performed.
3. Construct a network diagram : Using the activity sequence information, a network diagram can be drawn showing the sequence of the serial and parallel activities. For the original activity-on-arc model, the activities are depicted by arrowed lines and milestones are depicted by circles or "bubbles".
4. Estimate the time required for each activity : A distinguishing feature of PERT is its ability to deal with uncertainty in activity completion times. For each activity, the model usually includes three time estimates:
- Optimistic time : Generally the shortest time in which the activity can be completed. It is common practice to specify optimistic times to be three standard deviations from the mean so that there is approximately a 1% chance that the activity will be completed within the optimistic time.
- Most likely time : The completion time having the highest probability. Note that this time is different from the expected time.
- Pessimistic time : The longest time that an activity might require. Three standard deviations from the mean is commonly used for the pessimistic time.
Expected time for each activity can be approximated using the following weighted average:
Expected time = ( Optimistic + 4 x Most likely + Pessimistic ) / 6
To calculate the variance for each activity completion time, if three standard deviation times were selected for the optimistic and pessimistic times, then there are six standard deviations between them, so the variance is given by:
[(Pessimistic - Optimistic)/6]2
5. Determine the critical path : The critical path is determined by adding the times for the activities in each sequence and determining the longest path in the project. The critical path determines the total calendar time required for the project. If activities outside the critical path speed up or slow down (within limits), the total project time does not change. The amount of time that a non-critical path activity can be delayed without delaying the project is referred to as slack time.
If the critical path is not immediately obvious, it may be helpful to determine the following four quantities for each activity:
* ES - Earliest Start time
* EF - Earliest Finish time
* LS - Latest Start time
* LF - Latest Finish time
These times are calculated using the expected time for the relevant activities. The earliest start and finish times of each activity are determined by working forward through the network and determining the earliest time at which an activity can start and finish considering its predecessor activities. The latest start and finish times are the latest times that an activity can start and finish without delaying the project. LS and LF are found by working backward through the network. The difference in the latest and earliest finish of each activity is that activity's slack. The critical path then is the path through the network in which none of the activities have slack.
6. Update the PERT chart as the project progresses : Make adjustments in the PERT chart as the project progresses. As the project unfolds, the estimated times can be replaced with actual times. In cases where there are delays, additional resources may be needed to stay on schedule and the PERT chart may be modified to reflect the new situation.

PERT is useful because it provides the following information:
* Expected project completion time.
* Probability of completion before a specified date.
* The critical path activities that directly impact the completion time.
* The activities that have slack time and that can lend resources to critical path activities.
* Activity start and end dates.

The following are some of PERT's weaknesses:
* The activity time estimates are somewhat subjective and depend on judgment.
* Even if the activity times are well-estimated, PERT assumes a beta distribution for these time estimates, but the actual distribution may be different.
* Even if the beta distribution assumption holds, PERT assumes that the probability distribution of the project completion time is the same as the that of the critical path. Because other paths can become the critical path if their associated activities are delayed, PERT consistently underestimates the expected project completion time.

Defining a Task Set For The Software Project

No single task is appropriate for all projects. The set of tasks that would be appropriate for a large, complex system would likely be perceived as overkill for a small, relatively simple software product. Therefore, an effective software process should define a collection of task sets, each designed to meet the needs of different types of projects.

To develop a project schedule, a task set must be distributed on the project time line. The task set will vary depending upon the project type and the degree of rigor with which the software team decides to do its work. Most software organizations encounter the following projects :
- Concept Development projects : These projects are initiated to explore some new business concept or application of some new technology.
- New Application Development projects : These projects are undertaken as a consequence of a specific customer request.
- Application Enhancement projects : These projects occur when existing software undergoes major modifications to function, performance, or interfaces that are observable by the end user.
- Application Maintenance projects : The projects that correct, adapt, or extend existing software in ways that may not be immediately obvious to the end-user.
- Re engineering projects : These projects are undertaken with the intent of rebuilding an existing system in whole or in part.

DEFINING A TASK NETWORK
Individual tasks and subtasks have inter dependencies based on their sequence. A task network, also called an activity network, is a graphic representation of the task flow for a project. It is sometimes used as a mechanism through which task sequence and dependencies are input to an automated project scheduling tool. The concurrent nature of software engineering activities leads to a number of important scheduling requirements. Because parallel tasks occur asynchronously, the planner must determine intertask dependencies to ensure continuous progress toward completion. In addition, the project manager should be aware of those tasks that lie on the critical path.

Basic Principles of Project Scheduling

Scheduling is the culmination of a planning activity that is a primary component of software project management. When combined with estimation methods and risk analysis, scheduling establishes a road map for the project manager.

BASIC PRINCIPLES THAT GUIDE SOFTWARE PROJECT SCHEDULING
- Compartmentalization : The project must be compartmentalized into a number of manageable activities, actions and tasks. To accomplish compartmentalization, both the product and the process are decomposed.
- Interdependency : The interdependency of each compartmentalized activity, action, or task must be determined. Some tasks must occur in sequence while others can occur in parallel.
- Time allocation : Each task to be scheduled must be allocated some number of work units. In addition, each task must be assigned a start date and a completion date that are a function of the inter dependencies and whether work will be conducted on a full-time or part-time basis.
- Effort validation : As time allocation occurs, the project manager must ensure that no more than the allocated number of people have been scheduled at any given time.
- Defined responsibilities : Every task that is scheduled should be assigned to a specific team member.
- Defined outcomes : Every task that is scheduled should have a defined outcome. For software projects, the outcome is normally a work product or a part of work product.
- Defined milestones : Every task or group of tasks should be associated with a project milestone. A milestone is accomplished when one or more work products has been reviewed for quality.

Each of these principles is applied as the project schedule evolves.