Some tasks exhibit precedence relationships among them, and these should be taken into account when placing them in a time schedule. It obviously does not make sense to submit a paper for publication before we have written it. Even so, we still need to consider the order in which we are going to do them. Of course, we may just schedule one after the other linearly, but most often this will be highly inefficient. Once we have our duration estimates, allowing for work leaves and adjusted to local variations, we need to place tasks in time. Still, you should always find a way to reflect in your schedule the impact of work leaves, which will not usually be known in advance (See figures 2). Generally these will allow you to tailor the calendar to yearly variations. There are many tools that provide support for integration of calendar information from various countries. working days vary across cultures and countries, summer differs between hemispheres.). If you manage an international project you should then take into account local holidays and variations as well (e.g. Short projects may specify task duration in hours, but when planning any project that lasts more than a few days, we should always have a calendar (or more) at hand: when calculating completion dates you should add to the duration estimation holidays, non-working days, staff vacancies and so on. Most often we take it for granted, and tend to forget about its huge variability. That is why every project manager should try to keep a log of work and project performance and make post-mortem tests on every project to collect useful statistics that can be used to make future estimations more accurate (we’ll see more on this in an upcoming article in this series). Thus, at any rate, whenever possible we should try to include previous experience in similar tasks or projects, if possible from within our own Company, using performance records, or in their absence, using standard industry-wide estimations (often available from technical publications). Even experts may produce inaccurate estimates or task breakdowns for various reasons (ambition, optimism, ignorance.). Previous experience should always be taken into account. If possible, we should ask our experts to produce estimations. We can’t know the future, but often we may have an intuitive, more or less accurate idea of how long and how much work will be required to carry out each task. Estimating task duration is not easy as it involves a prediction (and a compromise). We need to make estimations on how long each of these tasks will take and fit them in a feasible schedule. At the same time we break down our project into suitable subprojects and further on down to leaf tasks, we must consider the time duration of each of them. Web based) where you may assign subprojects to other project members and defer further breakdown to them, thus sharing the work load (see figure 1). You will find the more relevant differences between standalone, single- user tools, where one person must centralize all the breakdown work (possibly collecting estimates from experts), and distributed tools (e.g. Almost any PM tool provides facilities for making a hierarchical breakdown of a project into tasks. In this case, we must do it ourselves, drawing from our technical expertise, previous experience or technical advisers, or a combination of all of these. Sometimes, however, this will not be possible, because you do not know in advance who will be responsible for doing what in the end. This may mean that you will need to call up meetings of developers/implementers to draft the plan, and perhaps include some of them in your meetings to discuss the plan with other key stakeholders. Whenever possible, it is better to rely on people who will actually do the work to produce accurate estimates of the time and resources required to achieve their sub-goals. for them by doing this, we’ll establish a hierarchy or network of responsibility among participants we’ll avoid being too intrusive on the details of how people carry out their work, which is often a serious source of dissatisfaction and problems and finally this acknowledges them as key stakeholders of our project (as the ones who must make it happen).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |