Tutorial 6: Keeping Projects on Track

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:

  • Dealing with a project that Ketura predicts will never complete;
  • Identifying when a project or milestone is slipping;
  • Reducing the amount of work to do by deferring non-essential issues;
  • Re-balancing work between users;
  • Re-balancing work between milestones;
  • Adding more users to the project and re-assigning tasks to those users;
  • Accepting a schedule slip;
  • Revising downwards estimates of work remaining.

Scenario

‘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.

1. Deal with a project that Ketura indicates will never complete

The Manage Projects page is showing that XYZ’s marketing campaign will never end. Why is this?

  • Ensure that you are logged onto the example database as Eric Samet, a partner at XYZ. Eric’s log on user id is ‘es’, and the password for this account is the same as the password for the ‘admin’ account that was provided during the installation of the Ketura server.
  • Click the global Projects tab navigation tab, near the top of the page. The Manage Projects page appears.
  • Select the Projects list tab.
  • Ensure that the Show drop-down list box indicates All projects.
  • Observe that the Actual or Expected End Date column for the ‘Marketing Campaign’ project in the table shows a warning symbol, with the word Never shown in red.
  • Click the Never warning. An explanation is shown which indicates that insufficient users’ time is allocated to the project for it to complete.
  • Select the Gantt tab. Notice that in the Gantt chart, the bar for the ‘Marketing Campaign’ extends all the way to the right, and has a ragged right edge. This shows graphically that the project will never complete.

Find out which users don’t have enough of their time allocated to the project

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.

  • Select the Projects list tab.
  • In the projects table, click the Marketing Campaign link to take you to the Manage Project Marketing Campaign page.
  • Select the Users tab.
  • In the table of users, observe that the Actual or Expected End Date column indicates that none of the users are going to complete the project. We still don’t know which user or users need more of their time allocated to the project.
  • Click each of the Never warnings in the Actual or Expected End Date column. Observer that only the top-most user, Andrew Wright, actually has insufficient time allocated to the project. All of the other users are being held up because of him.

Allocate more of a user’s time to the 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.

  • Click the global Users navigation tab, near the top of the page.

  • Ensure that the Allocation calendars tab is visible.

  • Choose the current year in the Show year drop-down list box.

  • Select aw [Andrew Wright] in the on the calendar for drop-down list box.

  • 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.

    Information 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.

  • Click the name of the first month containing red days.

  • In the Allocation of user’s time to projects table that appears, to the right of the calendar, notice that the ‘Marketing Campaign’ row indicates that a number of additional hours of Andrew’s time is required for the project to complete.

  • Notice that the bottom row of the table indicates, in red, the total number of hours of unallocated time on the selected days.

  • We’ll allocate all of the unallocated time to the ‘Marketing Campaign’ project. Check the checkbox on the ‘Marketing Campaign’ row in the table, then click the Distribute Unallocated button.

  • If enough time has been allocated to the ‘Market Campaign’ project for Andrew to complete his work on it, this will be indicated by an amount of time in ‘excess of requirements’ being shown in square brackets on the ‘Marketing Campaign’ row of the table.

  • If additional time is still required, repeat the previous five steps. If you don’t have at least one future month containing red dates in your calendar, choose the next year from the Show year drop-down list box and allocate all of Andrew’s time in January to the project.

Verify that the project will now complete

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.

  • Click the global Projects navigation tab, near the top of the page.
  • Select the Projects list tab.
  • Observe that a predicted end date for the ‘Marketing Campaign’ is now shown in the Actual or Expected End Date column.
  • Follow the Marketing Campaign link to the Manage Project Marketing Campaign page.
  • Select the Users tab.
  • Observe that all users now have an Actual or Expected End Date.

Information 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.

2. Identify a project or milestone that is slipping

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.

  • Screenshot showing Gantt chart with slipping projectsClick the global Projects navigation tab, near the top of the page.
  • Select the Gantt tab.
  • The orange diamonds on the Gantt chart indicate the desired completion dates of each project. The blue bars indicate the actual or expected duration of each project, based on the work remaining estimates made by the assignees of all the project’s tasks. The orange bars indicate the planned project durations, based on the planned work estimates for each task that comprise the official project plan.
  • Slipping projects are easily spotted: the orange diamond (representing the desired end date) of a slipping project will appear before the right edge of either the blue (actual or expected schedule) or orange (planned schedule) bars.
  • Select the Projects tab and follow the Client ‘Extended Ltd’: Create Asset Tracking Software link.
  • On the Manage Project Client ‘Extended Ltd’: Create Asset Tracking Software page that appears, select the Gantt tab.
  • Observe that the predicted schedules and desired end dates for every milestone in the project are shown. Each slipping milestone can be readily identified, and it is clear that every milestone has significantly overshot its desired end date. It seems that XYZ has been rather optimistic about how quickly it could implement its new software when it set desired end dates for this project’s milestones.

Information 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.

3. Reduce the amount of work to do by deferring non-essential issues

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.

  • In the sidebar to the right of the page, go directly to the issue’s page by entering I1132 into the By issue id/content or task id field under the Find section, and then clicking the Go button.
  • Select the Schedule tab of the issue page that appears.
  • In the Reschedule issue section, ensure that the top checkbox (next to the drop-down list box containing the options Move and Add) is checked.
  • Ensure that the first drop-down list box has its value set to Move.
  • Select X1 – Deferred milestone under the group Client ‘Extended Ltd’: Create Asset Tracking Software in the to milestone drop-down list box.
  • Check the checkbox next to the Change the state to drop-down list box, and ensure that the drop-down list box shows Deferred.
  • Ensure that the checkbox next to the Assign drop-down list-box is unchecked. We are going to place the issue into the ‘Deferred’ state, which is inactive. Any outstanding tasks will therefore be marked as complete automatically, so we don’t wish to reassign them.
  • Click the Apply button.
  • Observe that the Milestones section of the Schedule tab shows that the issue is now on the ‘X1 – Deferred’ milestone of the project. Likewise, the Details tab shows that the issue’s state is now ‘Deferred’. Finally, the Tasks tab shows that all the issue’s tasks are now marked as complete.

4. Re-balance work between users

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.

Information 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.

  • Go to the Manage Milestone M4 – Final Release page of the asset tracking project. This might be listed in the Recent pages tab in the sidebar to the right of the page. If not: global Projects tab > Projects list tab > Client ‘Extended Ltd’: Create Asset Tracking Software link > Milestones tab > M4 – Final Release page).
  • Select the Users tab.
  • Notice that John Street’s Actual or Expected End Date is somewhat earlier than those of the other users, whereas Andrew Wright finishes last. It looks like there is scope to reassign some work from Andrew (the company administrator and office manager) to John (the QA manager). Obviously, this can only be done if John is able to undertake any of the work currently assigned to Andrew.

On which issues does Andrew still have work on milestone M4?

  • Select the Issues tab.
  • In the Filter by row, in the <tasks remain for…> drop-down list box (the last one in the row), select aw [Andrew Wright]. Make sure that all of the other filter fields have the top, angle-bracketed, options set, so that they are not filtering the issues.
  • Only issues I1134 and I1135 are now listed. These are the only issues for which Andrew still has work on this milestone. For the sake of this tutorial, let’s assume that John is able to stand-in for Andrew and undertake his work on both of these issues. We could go to Tasks tab of each of these issue’s pages, and manually re-assign each of Andrew’s tasks to John. However, there is a better way of accomplishing the same result.
  • Check the checkbox in the header of the right-most column of the issue table. The checkboxes for both of the issues in the table are automatically checked.
  • Click the Act On… button. The Act On Selected Issues page is shown.
  • Select the radio button next to Assign tasks assigned to.
  • In the first drop-down list box on the same row, select aw [Andrew Wright]. In the to drop-down list box, select js [John Street].
  • Click the Apply button. You are returned to the Issues tab of the Manage Milestone page.
  • Notice that no issues are shown. This is because the list is still filtered to show only issues with work remaining for Andrew Wright. Change the filter back to <tasks remain for…> to show all the issues again.

Has this improved the end date for the milestone?

  • Select the Users tab.
  • Success! Notice that the end dates for all the users are now much closer together. Andrew Wright is no longer listed on this tab, since he no longer has work on this milestone.

5. Re-balance work between milestones

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.

  • Go to the Milestones tab of the Client ‘Extended Ltd’: Create Asset Tracking Software page. Follow the relevant Recent pages link, or: global Projects tab > Projects list tab > Client ‘Extended Ltd’: Create Asset Tracking Software link > Milestones tab.
  • Create a new milestone, ‘M5 – Follow-up Release’. We’re going to use this milestone to plan a follow-up release containing the things that couldn’t be completed in time for M4’s deadline. Each user’s work on the milestone can start separately. Choose a desired completion date that is a month or two in the future.
  • Make sure M5 immediately follows M4 (so that it is before X1) in the project milestone order.
  • Using the selection checkboxes on the right of the milestones table, select milestones M4, M5 and X1.
  • Click the Re-balance… button to go to the Re-balance Milestones page, showing all the issues on the selected milestones.

Screenshot showing Re-balance Milestones page

  • Looking at the list of issues in M4, there doesn’t seem to be much that can be delayed. However, XYZ considers that I1130 is not going to affect the client too much, and can therefore wait. Also, it decides that I1132, which we deferred earlier, can now be moved to the new milestone.
  • In the M5 – Follow-up Release column, select the radio buttons for the I1130 and I1132 rows.
  • Click the Preview button and observe the change in the predicted dates at the bottom of the table.
  • Since the revisions are acceptable, click the Apply button to save them.

Information 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.

6. Add more users to the project and re-assign tasks to those users

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.

7. Accept a schedule slip

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.

  • Return to the Milestones tab of the Client ‘Extended Ltd’: Create Asset Tracking Software page.
  • Notice that the End Date Variance for M4 is highlighted in red, indicating that the actual or expected end date exceeds the desired end date.
  • Use the selection checkboxes in the right-most column of the milestones table to select milestones M4 and M5.
  • Click the Set End Date button.
  • Notice that the desired end dates for both milestones are now the same as the actual or expected end date. The End Date Variance column now shows zero variance between the two dates.

8. Revise downwards the estimates of work remaining

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.

  • Go to the page for issue I1129 (use the Find section in the page sidebar).

  • Select the Tasks tab.

  • For tasks T1595 and T1596, reduce the Planned Work to 2h.

  • 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.

  • Click the Apply button to save your changes.

Go to the next tutorial