Validating your assumptions is always a good practice. In project management too you should be validating your assumptions about everything. Most of the things about how much work has been done, how much more work needs to be done etc. are not something you can attach a precise numerical value. We do attach a percentage quite often. But that, more often than not, is an indicative value. Validate the way you are doing things. Is that absolutely the right way? The outcome you expect is that clearly validated and measureable? We talked about how a success criteria needs to be defined. This is an attempt to define the project outcome as precisely as possible. Once again, since it is difficult to attach numbers, they are descriptions. Unless they are validated and agreed to between the parties, the meaning of these success criteria could be truly different. Unless validated, the actual situation may be quite a bit off and these numbers would look like wishful thinking.

Validate Often

Validation must be a constant iterative cycle for you, the project manager. This must start with the decisions you made during the work breakdown structure that you created. Is that the best possible breakdown? Does that make the best sense given the technology, skill and competence of your team members? Remember, statistical data says there can be a wide range of variation in productivity with similarly skilled people! Some assumptions you had made may need change to get effective QA done.

Sequencing of the tasks/activities involves a lot of assumptions too. As you progress through a project things change and some assumptions become clear, some assumptions may be good to be discarded even. That will have a direct impact on the timeline. Thus, unless constantly validated, it is easy to go completely wrong and get bogged down. While the initial plan is a good reference point, you must be certain it is not cast in stone. Changes are necessary. It is this frequent local corrections that can keep a project plan on track. It is certainly impossible to take care of every issue during planning stage. Unless the local corrections are done often enough a plan can never be realistic.

Validate where you are against where you are expected to be. There are no clear latitudes and longitudes you can use that’ll pinpoint where you are at any given moment. Hard measurements are not appropriate, as we have discussed many a times. So we need to constantly evaluate and validate how much is done and how much needs to be done. Project outcome definitions, particularly the intermediate outcomes defined and the success criteria already negotiated with the senior executives have direct implications on where you are. Thus you do need to validate these outcome and success criteria constantly.

When you are convinced deviations have occurred you have to plan mitigation, corrective actions immediately to ensure that everything is aligned correctly to bring you the desired outcome. You need project success then validate, validate and then validate again. There are no two ways about it.

Key to successful time schedule management of a project is proper breakdown of tasks that are necessary to complete the project. Assuming you do a very efficient job in breaking down a project into logical tasks and sub-tasks, the project can still run-away unless these tasks and subtasks are done in the right, logical sequence. While the logical relationship of sub-tasks that must be executed to carry out a task may be clear, same is not true of the sequence of tasks to be done to achieve your goal.

Correct Sequence

Determining the correct sequence necessary to carry out the tasks and related subtasks takes a lot of skills on the part of the project manager. He needs to understand not only the parts of the product or the project task but also how the parts connect together to get you the final product or services or whatever it is that you are creating through the project. Unless the correlation of parts to the whole is understood, you would not be able to sequence the activities in the most efficient manner. The understanding that the engine of an automobile must be completely assembled and tested before it can be fitted to the automobile body defines the sequence of actions, for example. Therefore, what the product is can largely determine what sequence is appropriate to assemble it. From a entirely different product category, you have to have the hosting hardware and software ready before you can start uploading a web page and test.

Dependencies-Internal as well as External

Depending on how a project is planned a lot of factors influence how and when a task can be carried out. For example, unless supply of tires are adequate you may have to halt automobile production. You may delay the addition of tires until the fully assembled car is driven off the assembly line. But then you must have the wheels necessary available at that point. This clearly is an external dependency that can ruin your time schedule. The other example of the engine being ready before integration is an example of internal dependency assuming the engines are produced in house. Remember that the examples are taken from a simplified scenario.

Depending on the design of the automobile ( a car, truck or a commercial vehicle) the engine may get fitted on to the automobile chassis at various stages. It can be right after the chassis is ready. Therefore, what we see as dependencies will actually depend on the process being carried out too. In a similar vein, when you integrate two parts of a software product can vary in a lot of ways. You may start integrating bottom-up by integrating small modules. Alternately, you may integrate top down when functional modules are ready. Yet, as a project manager you need to have a very clear overview of the effects of changing the sequence of tasks that go into the project. What must be done in a strict sequence, what can be overlapped, and when these parallel threads meet the main sequence need to be taken care of for successful completion of your project.

Correlate and sequence your tasks appropriately. Identify interdependencies between the tasks. External dependencies.

Organizing the activities in a project works well for executing a project. It works well for monitoring it too. When you have been able to organize the tasks and sub-tasks in a well defined structure, it can give you a good feel of what parts need to be ready for progressing to another phase for a project. For organizing a project well the work breakdown structure or the WBS needs to be clearly defined. The smaller the individual items of the WBS it is more accurate to measure percent completion as you can identify these completions of tasks very clearly.

Facilitates Monitoring

When you have a clear break down schedule the project manager is able to sequence the activities for the most efficient completion. This is in terms of both time and cost targets. The set of tasks, organized in a fashion that shows what path the execution must take, clearly lets you visualize the way forward. You able to very clearly identify how much has actually been done too. The biggest problem in project time schedule monitoring are these two issues; that of being able to clearly figure out how much has been done and how much more needs to be done for completion. The project tasks/sub-tasks sequencing defines the structure of activities being carried out and to be carried out. Should there be problems or you can foresee a problem coming up you are able to think up some local corrections that can mitigate the effects of the problem. Since, except in ideal conditions, these local corrections are always necessary. More frequently you can monitor status and can visualize issues and take corrective actions, more likely you are to reach the goal we all desire. That of the successful completion of your project.

Create Understandable Sub-structures

Since the sequence of tasks and the organization (the way tasks are strung together to achieve a goal) it is essential that we are able to break down the overall plan into pieces, the sequence and organization of which, we can grasp easily. It is only so much that we can understand at a time. As we have seen that’s vital from not only assessing exact status but also for determining how much more needs to be done. All the other related peripheral activities are also clearly visible. This may take the form of ensuring some vital supplies arrive in time. It may be necessary to monitor milestones on a related project to ensure some parts you need, are ready in time. This understanding of the shape of the project is vital for you as a project manager.

Therefore always breakdown your project time schedule to intermediate milestones such as releases, iterations, phase or what have you. But ensure that these stages are not so big that details can cause confusion in understanding the state of affairs. Do not break them down to so small pieces that they are trivial to understand and the details are too much to give you a understanding of the complete project time schedule and the ultimate goal.

While you may have planned your project meticulously, derived a perfect WBS, sequenced the activities wisely and organized the whole plan every effectively, you need to allocate resources that can make the plan a reality. Had these resources been machines you would have estimated their skills, productivity etc very accurately and you would not have to worry about motivating anyone. However, we deal with human beings and skills, productivity and motivation levels can vary widely. How well you are able to apply resources and how well they produce results will determine the quality of your outcome and will determine the time and money consumed by the project.

Allocate wisely

So allocate wisely- that’s an obvious advice! How do you do that! It take both hard and soft skills. You need to be aware of the technology to be used, the implications of design choices that are made as also the implications of sequencing and organizing the tasks. On the soft skills front you need motivating skills. The ability to assess skill levels of personnel and the productivity levels you can expect from a resource. Besides the need for being accurate about the resources, you may have to do jugglery acts about resources that may not be available to you full time.If you are involved in an multidisciplinary and/or inter-departmental project, you are going to need heavy duty negotiating skill to recruit the right resource from the other department for your project. You may need influence through the project life-time if the person is not allocated full-time to you. Quite often such projects work on the skunk works set up. It is basically a task force that works in a separate area for the project duration.

During the monitoring periods you have additional tasks and corresponding corrective actions in addition to what is required by the project otherwise. You have to keep the motivation levels up and hence constant monitoring of motivation. Besides take frequent look at if the resources applied are the right type in terms of their skills, productivity levels and motivation level. You will need to be very hard headed here. The outcome of your project is your topmost priority. If that calls for a change in resources so be it. Move quickly and get the necessary act done. Communicate effectively so that such moves do not have an adverse effect on the moral of the team. Communication will be a constant burden you will have to bear. Starting from getting the buying-in, estimating, defining success criteria and the intermediate outcomes, the job never stops.

Be realistic

As a project manager you have to be very pragmatic. Be very realistic in assessing who are the right resources. Be realistic in estimating skills, productivity and motivation levels. And that’s just the starting phase of the project. During the lifetime of the project never let sentiment or personal liking colour your judgment about who needs pep talk, who need public appreciation, what results to be communicated to the higher ups and what you need from them. You may have to be demanding but be able to talk in their terms.

A picture is worth a thousand words. That is equally true in case of planning and monitoring the time schedule of a project. Depiction of tasks, interdependence of tasks, the sequence and the organization can actually be shown by a drawing. The picture produced by a few simple drawing artefacts is able to depict these interrelationships and even external dependencies. If you need to divide the project into understandable sub structures the drawings produced by Gantt charts can give you that too.

The Gantt Chart

The Gantt chart is a tool developed by an American engineer Henry Gantt. Though he had developed it as a production control tool it is now used in project time schedule depiction and quite effectively. With a few simple elements this tool can bring out the complete interrelationships of tasks in a project, the sequences used to implement the project and thus the overall structure. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the WBS of the project. Gantt charts can be used to show current schedule status using percent-complete shadings and a vertical "TODAY" line.

It is really a horizontal bar chart. Each bar depicts an activity and it is shown against a timeline that appears on the horizontal scale of the graph. Vertical axis is not to scale and the activities are described one after another vertically. A corresponding horizontal bar shows the star of the activity and ends at the time when the activity is supposed to end.

So the time relationships of the tasks are immediately apparent from the diagram. Parallel activities appear vertically separated yet over similar time scale. Activities that must follow one another appear sequentially on the chart. Dependencies are depicted by a line. For example if the end of an activity is a necessary pre-condition for the beginning of another, a line with an arrowhead shows that dependency. The line extends from the end point of the activity which must complete before the other can begin. The line ends up at the start point of the next activity that depends on it. So that one look at such drawings and the dependencies are immediately very clear. Though other types of dependencies also can be shown, it is this relationship that is used more often.

It is immediately obvious, the sequencing and the organization and the WBs that we emphasized in earlier sections makes drawing the Gantt chart that much more effective. The diagram brings out sequential relationships between tasks, if one activity is dependent on another, the overall structure etc. can be visualized very easily. Immediately, the chart turns into a very effective tool for status reporting and a monitoring tool. It clearly speaks the language of time schedules and makes it easy for describing to other stakeholders what’s going on with the project.

For breaking down a project into bite sized chunks, parts of the chart with clearly defined intermediate milestones can help you visualize the pieces equally easily.

Time estimates are a crucial part of project planning. We start with the WBS to be able to plan the activities well. To get any optimization done with these activities such as the sequencing and organizing the activities we have to have time data. The time data to start with are the estimates of the duration of each of the activities. You then arrange the activities with the correct sequence and organization. This is when you are able to make out what activities can overlap others, what intermediate milestone we can plan for etc. Depending on the internal and the external dependencies, you are able to decide when can each of the tasks start and end. This is when you are able to come up with such additional time parameters as the early and late start as well as early and late end times. At this point you would be able to clearly identify the critical path too. The critical path is the longest chain of activities, none of which has any slack/float. This is the path that decides the total duration a project is going to take.

Estimate Accurately

Time duration estimates of all the tasks and sub tasks are important as we have seen. The estimates need to be accurate if we are to come up with an accurate project duration estimate. It is usually easy to estimate the time an activity could take, when you know everything about the task. In a manufacturing scenario, you usually have accurate estimates of the tasks involved in producing a product. Projects are usually about doing something for the first time. Since your business has been operating in a given domain area you would probably know many things and be able to estimate many of the activities accurately.

Difficulties in Estimation

But, in the project mode there’s always something new to be handled. For example, while you may operate in the building construction business, every building you construct will throw up some new challenges. Accurate estimate for such activities would really have to be a good guess. An educated guess, but a guess all the same. Knowledge based projects and software product development projects offer a huge challenge in estimation. Quite often it is a product you are trying to develop for the first time. Though you and your organization may have dome something similar it was not quite the same. Estimate for something new could vary widely. You may achieve an early breakthrough saving time. On the other hand you may be totally off in estimating the development time.

What then does one do? One practical way to do this is to ask your experienced leaders to bid on estimates. Take couple of the lowest bids and ask for improvement on that. You can try to ask for optimistic and pessimistic estimates and arrive at a statistically valid mean. Another way would be to use some well known models like the COCOMO that simulates the software development processes and come out with an estimate. However, it is so difficult to simulate the development process this model is not used very often.

It’s not only your project team members and you the project manager that are the only stakeholders in a project. There are always a lot of other stakeholders in the organization that are interested in successful completion of the project you are handling. They would want to be informed of the progress. The frequency of the reporting would depend on the criticality of the project to the organization’s goals. As a project manager you are in the middle of your project team and these other stakeholders. We have discussed already how it is vital to communicate with the project team. It is equally vital that you are able to communicate with these stakeholders as well.

Communicate, Communicate and then some more

These other stakeholders are not interested in how you are getting the project done, the processes, the technology involved and so on. Their information need is going to be entirely different than your day to day concerns to get the project done successfully. They would obviously be interested in knowing how much has been done and how much more needs to be done. Now, as a project manager you need to have a very accurate grip on these two aspects anyway. But what the higher honchos need to understand is not if you finished the critical server component in the latest and greatest software. What they would probably want to understand is the time to market aspect of the product. So you must very clearly understand what is it that they want to know, in their terms.

Your job would be to understand what exactly they want to know. To do that you w2ould need to communicate frequently with the people that matter and really listen to what they say. Only then you would be able to understand what they want to know and understand. When you are ready to report the status communicate the information in the required format. This correct articulation of the how much is done and how much more needs to be done will save you a lot bickering at later points in time.

Like everything else in corporate life, be as accurate and as realistic as possible in your reports. Quite often, particularly when you are assigned to be project manager for the first time, you may tend to report quick progress and early breakthroughs. This would typically be in the first flush of enthusiasm to prove to the world ho2 hot shot a project manager you are. However, remember that being too optimistic raise expectations all round. It is possible that in the early adrenalin rush, you have actually produced very optimistic result or even a breakthrough. But, what you need to consider is, if that kind of progress is sustainable.

Remember the other side too. While it is possible to may be push your team quite hard initially and get some quick results, it is nearly impossible to maintain that over a period of time. Project folklore is replete with stories of how such project managers succeed in creating death marches. People continue through the pressure, but reach a zombie like state where they would not really care about what is being produced or what the goal was. Communicate with them realistically too.

If it is important to know what’s on your plate, it is equally vital to know what’s not on it. It is the complementary part of the requirements definitions. If we define a set as well as another set that is distinctly exclusive from this set then the set gets uniquely defined. Therefore, if our scope definition comes with a set of things required, the things that are not required makes things very clear indeed.

What’s NOT on Your Plate

Language is not a very precise thing. Thus it is often very difficult to pin down the requirements, where it can be used as a clear measurement of a scope having been fulfilled. What’s not in the requirements makes the scope boundary to be defined more precisely.

There’s one more reason to look at what’s not included. This is to define customer expectations more precisely. This may be feature that is not to be developed. Including these features may adversely affect your development schedule while the incremental value-add may not justify the time spent. Like documenting the scope as accurately as possible, you should document what’s not included also as accurately. If it is for defining customer expectation boundaries, it should be in a document that is meant for review by customer. This forms a basis of discussion with customer. The exclusions get clearly discussed and you get concurrence of customer. There will be situations when customer may not agree on the proposed exclusions. But, then that would be an opportunity for actually discuss the change in scope and the changes in time and budget, if any.

Not documenting these exclusions can do two things. One, the customer would expect the features to be developed. Not mentioning these explicitly could appear as if you have overlooked the issues. Even though you have moved these items to exclusion list, not documenting may leave these un discussed leading to later problems.

External Dependencies

It is equally important to document what’s not in the project scope even when external customers may not be involved; if your project is part of a larger project, for example. Once you have documented the boundaries of your project scope, what’s outside the boundary will tell you the dependencies very clearly. Wherever the bigger project needs your deliverable to get an activity started it is dependent on you. But, when your tasks cannot start until deliverables from other parts of the project has happened, you are clearly depended on them. Documenting these external dependencies not only brings them on the mind map, you also have hard dates, success criteria , task outcome defined that tells you if it is time to start your tasks. This document then can be a monitoring tool at inter-departmental meetings. You would need to know the progress on these items for successful completion of your tasks. Those dependent you would similarly be following up on the tasks they have to depend on. Overall success would thus depend on these mutual success of connected tasks.

You have done your WBS. You have been able to sequence the activities for the most effective outcome of the project. You have organized so that structure of the project plan is clearly visible. What remains now is to represent the activities in a network diagram. This clearly shows you the interrelationships of activities. Each activity has a duration attached to them. This is the time it takes to complete the activity. No variability in the out outcome is taken into account, so use one number that you know to be fairly accurate. For each activity consider four other time parameters the earliest start, earliest finish, late start time and the latest end times. The difference in the late and early start as well as early finish and latest finish define the time margin or float. If the task were to start anywhere during the leading float and end anywhere within the trailing float the outcome will not be affected.

The Critical Path

When you traverse any path in this interconnected diagram if you add up the duration estimates as you go, it’ll tell you the total time it takes to go through the sequence of events that you traverse. The critical path is the path with the longest duration. The set of activities on this path have to be completed on time otherwise the total timeline of the project get extended. The Gantt Chart is a representation of such a network. The tasks/activities that represent the longest path is the critical path. Obviously then, any delay in completing any of the tasks on he critical path will delay the project completion. Also note that the overall duration cannot be reduced as there are no floats associated with the tasks on the critical path.

On the network diagram or the Gantt chart there will be one or more set of activities that cannot be optimized to reduce the time taken by reducing any floats associated with these activities. They do not have such floats. There will be many other activities for which start and stop times can have some margins. As long as the margins are not exceeded, the outcome is on time and does not affect the overall time schedule.

Watch the Critical Path like a Hawk

In general, you should be watching any path that have low or nil float. But, the critical path, the set of activities it represents, is the one to watch all the time. Monitor them more frequently if need be. Have resources available for these tasks al he time. You should not only be watching these activities, you should keep an eye on the other activities that have dependencies with any activity on your critical path. Essentially do whatever it takes to make carrying out of these tasks smooth.

To help monitor the project better and to make the critical path obvious. It is a good practice to lay out the critical path so that it is the central part of your chart. Other activities can be laid out that are parallel to these activities.

One of the reasons we need to define the scope of a project very clearly is to be able to communicate to our customer that we did understand their needs. Understanding and the ability to define the scope needs to be communicated to customer in as unambiguous a term as possible. Therefore there’s these two part to the interaction with customers. The first is the comprehension and the skills to understand the problem domain. Second is a set of issues that have a direct impact on how you plan and manage the time schedule of customer project. The ability to understand the customers and his needs is thus of vital importance. For effective management of time schedule you’ll need to understand what’s important for your customer. Similarly what’s urgent also is equally important to understand.

Once you have broken down your project into a work breakdown structure there two things that decide the sequence in which your tasks are to be organized for deliverables. While some of the tasks will need to be completed in a specific sequence decided by the requirements of the development technology; overall sequencing needs to be driven by the urgency and the importance of parts of the product.

It is always a good idea to be able to do intermediate releases of a product rather than one big bang at the end of the project. Partial products let the customer get a hands-on feel of how the product is going to behave. It also gives everyone an opportunity to make sure that is the kind of thing they needed or wanted. If there are minor modifications to be done, here’s an opportunity for a correction cycle. Rather than contributing to scope creep this may be a way of aligning with customer expectations. To make this possible you have to understand what’s urgent and what’s important to the customer so that your time schedule plan can take those tasks that are required to deliver these intermediate products. You should clearly schedule the task sequences that deliver the urgent features. Important issues also help you decide what tasks to schedule after what task. It may also make you focus on additional tasks that need to be taken into account. For example, you may need to schedule additional QA activities to ensure robustness of the important feature set.

Communication is of Paramount Importance

What starts in a project with interviewing customers to make sure requirements are un ambiguous, must continue through the life time of the project in constant attention to listening and communicating. As a project manager this is one of the most urgent issues to devote your time on. Listen closely, document the understanding, discuss, modify the documents goes the cycle that must be followed to ensure you understand you costumer and his needs well. That probably is the biggest precondition of your project success.