This tutorial takes about 60 minutes and is intended primarily for project managers.
When a project or milestone starts to slip, the project manager will typically wish to take some action to bring it back on schedule. There are several potential courses of action available, as discussed in Ketura Tour Step 5: Keeping Projects On-Track. This tutorial covers the practicalities of putting those remedies into effect. It covers:
‘How does a project get to be a year late? One day at a time.’
So said Frederick Brooks in his landmark book, The Mythical Man-Month 
.
Keeping a project on schedule therefore requires careful and diligent daily action by the project’s manager. Since a project can be a very large undertaking, with hundreds or thousands of issues, it is usually easier for a manager to focus on keeping project milestones on track. If all of a project’s milestones are on schedule, the project as a whole will also be on schedule. Ketura gives project managers the schedule information they need, both for individual milestones and for projects as a whole.
This tutorial assumes that you have the example database installed. This database illustrates various Ketura concepts applied to a fictional firm, XYZ, Inc.
XYZ wishes to bring two slipping projects back on track: its marketing campaign, and the development of its asset tracking software for Extended Ltd, one of its clients.
The Manage Projects page is showing that XYZ’s marketing campaign will never end. Why is this?
We now know that not enough users’ time has been allocated to the marketing campaign, and so it will never complete. But which users need more of their time allocated to the project? The warning tells us that, to find out, we need to visit the Users tab of the relevant project.
Only Andrew Wright needs more of his time allocated to the project. We could perhaps solve the problem by reducing the amount of work that Andrew has to do on the project. However, the easiest way to address the problem is to allocate more of his time to it.
Depending on the current date, you should see one or more future months on the allocation calendar where with days shown in red. These are days upon which Andrew Wright has unallocated time.
We are only interested in setting allocation for future dates, because Ketura ignores any allocation that is in the past when
calculating schedule predictions. This is because no further work can be performed on days that have already gone by.
We have now allocated enough of Andrew’s time to the marketing campaign. Let’s see whether this has solved the problem of the project never completing.
For a real project, it might well be the case that several users have insufficient time allocated to a project. In such case,
simply deal with one user at a time, allocating additional time to the project until the problem is solved.
A project or milestone is said to be slipping if it is not predicted to be complete by its desired completion date. For a project, the desired completion date is simply that of the last milestone with work in the project.
Click the global Projects navigation tab, near the top of the page.
The Detail tab of each project and milestone provides extensive data about how the project or milestone is progressing, including variances between the desired and predicted end dates.
In the previous step, we saw that the project to create an asset tracking system has fallen significantly behind. In fact, a glance at the Gantt tab of the Manage Project Client ‘Extended Ltd’: Create Asset Tracking Software page shows that M4 is expected to complete many months later than intended. Clearly, action needs to be taken to tame the project. The remainder of this tutorial shows various steps that can be taken to rein-in such a project. One wouldn’t usually pursue all of these steps, but it is useful to learn about them all.
One way of tackling a late project such as this is to put off some non-essential work, perhaps indefinitely. This is straightforward to do in Ketura, but can be difficult if a project’s goals are inflexible. XYZ has decided that I1132 (an enhancement planned for M4) can be deferred.
Work can be re-balanced between users by, for example, re-assigning the tasks of one or more issues from one user to another. This can be effective if one user is due to finish a milestone or project before the others. The Users tab of each project and milestone shows the predicted end dates for every user, so it is easy to see whether any users are expected to finish before the others, and might therefore be able to accept more work.
This course of action might not be possible if all the users are behind schedule, or if it is not easily possible to reassign
work between users. This might be the case if the work requires specialist skills or training.
On which issues does Andrew still have work on milestone M4?
Has this improved the end date for the milestone?
This approach is helpful where it is important to meet a particular milestone, but where some of the work currently planned for that milestone can be postponed to a later milestone. Of course, this does not bring forward the completion date of the project as a whole, but that might be of secondary importance.
Ketura facilitates such re-balancing by enabling project managers to compare two or more of a project’s milestones, showing all the issues in each milestone. Each issue can then be moved between milestones with a single mouse click. The effects on the milestone schedules can then be previewed, before the changes are committed. Using this process, drastic changes can quickly and efficiently be made to a project, even if dozens of issues have to be moved.
Although both issues have been moved to M5, I1132 is still in the ‘Deferred’ state. If this were a real project, we would
visit the issue and change its state to ‘Pending Resolution’, also checking that its task assignments and work predictions
are reasonable. In general, when you move an issue out of an inactive state, you need to treat it in roughly the same was
as you would a new issue.
For some kinds of project, using extra staff can be an effective (albeit potentially expensive) way of bringing a project
back on schedule. However, it has long been recognized that there are many types of project where adding extra workers will
slow things down. This is due partly to the increased communications overhead needed to run larger projects, but also because
the new workers need to be trained and managed, often by existing project members. Frederick Brooks (quoted above) wrote about
this phenomenon within the context of software development in his classic book, The Mythical Man-Month .
Attempting to accelerate a project by adding more users is virtually identical to the procedure covered by 4. Re-balance work between users. The only difference is that work is assigned to users not currently on the project, instead of between users already working on it. Because of the similarities, it is not discussed further here.
Despite all the action taken thus far, the project ‘Client ‘Extended Ltd’: Create Asset Tracking Software’ is still not going to meet its desired end date. In fact, the desired end is in the past. Therefore, XYZ has to accept some sort of slip in its desired end dates for the project’s remaining milestones. It has therefore decided that it will accept the current ‘Actual or Expected End Dates’ for M4 and M5.
Unless there is a genuine reason to believe that there is less work outstanding than previously believed (perhaps unlikely, given that the project is already slipping), this approach is nearly always inadvisable. It risks masking genuine and serious problems in your project or milestone schedule. When endeavouring to keep a project on track, it is advisable to tackle problems properly at the earliest opportunity, instead of manipulating the schedule to pretend that they don’t exist. In general, the best way to reduce the amount of work outstanding is to defer non-essential work until a later point (see 5. Re-balance work between milestones, above).
All that said, XYZ is confident that it has over-estimated the amount of work needed to resolve I1129.
Do the same for Work Remaining.
It is important to realize that a project manager who reduces the expected work remaining estimate for a task is overriding the (probably informed) opinion of the task assignee who made it. This is unlikely to improve the accuracy of the resulting schedule predictions. If a project manager genuinely believes that a user has over-estimated the work outstanding on a task by a significant amount, it is better for the project manager and the user to discuss the matter to reach an informed conclusion.
