decisionAccelerator 4.21 Released

General

• Update portfolio example to be compatible with the new context menu

• Speed improvements calculating the consistency when performing the pair-wise judgements

fastProject 4.8.14 Released

General

• Made compatible with all regions where e.g. list separators, currency formats, etc. vary

• Resource Tables added back to Global

• Context Menu reworked (removed: Add Action, Notes & Highlight, added: Update Task)

• Problem fixed with “Link to Last Milestone” where some VBA commands available in 32-bit MS Project were not available in 64-bit MS Project

Tools

• fastBuild

  • Bug fixed where the Project Mission box in Step 2 (Milestones) would shift right each time the user when back to Step 2

• Bug fixed where adding a Touchpoint, Checkpoint or Deliverable did not update the Inspector

Update

• Target selected after an Update now determined by the setting of fastProject Options > Inspector > Default Target

Wigglechart

• Wigglechart now lists the gap (days early/late) in the summary information when a milestone is completed.

Inspector

• New function “Focus Now” added. Lists all tasks that meet criteria based on: the Target milestone selected (or Project), Starting/Finishing before a selected date, Days from Critical Path within a set number of days, and where the task is optionally Not started/In-progress.

• Added ability to turn on/off summaries within No Group is selected for the Late Report

• Fixed bug where closing the Late Report using the ‘x’ in the top right of the form would exit without resetting the schedule

• Fixed bug where Target milestones were also listed

• Clarified the number of days late are calendar days when the gap button is invoked

fastProject 4.8.13 Released

General

• Fixed start-up error if “ Show the Start screen when this application starts” was checked in Options > General

• Fixed bug where tasks would be sorted by the Late Start by default

decisionAccelerator 4.20 Released

General

• Right-mouse click menu added for faster access to dA functionality:

  • Context menu items are sensitive based on whether the cell is an Objective, Alternative or Constraint

  • Clicking anywhere else on a model reveals a reduced set of Excel functions

  • Reset Priorities is always visible when on a model, no matter where the user clicks

  • Clicking on a non-model reveals the standard Excel menu

Alternatives

• Bug fixed where it was possible to delete the first alternative in the list when there was only two alternatives (the user should have been prompted a model must have a minimum of two alternatives).

fastProject 4.8.12 Released

General

• Negative Float line added to milestones in the FP::model view

• Fixed bug where “Link from first task” would cause an incorrect row much later in the schedule to be selected, which in some cases gave the appearance that all tasks had disappeared

• Automatic recalculate now overs when a file is opened so custom fields are automatically recalculated

Tools

• Importing a schedule

  • All task bars now visible (not hidden)

  • Fixed bugs where blank lines were not removed

  • Fixed bug where summary tasks were set to Manual if any of the subtask’s durations were set to estimated

  • Fixed bug where, the import would fail if a task had been broken down into subtasks between issuing the LAR and importing it.

Analyzer

• Tasks Late To Target Simulator * NEW *

  • A new feature that answers the question “How many days do I need to pull-in each task to hit my Target date” has been introduced, located under the CP Analysis button in the Inspector.

  • First select a Target from the Inspector

  • Select one of three views - tasks that are Late to Target, On-time to Target and All tasks to Target. The tasks late to Target have negative float and two columns are added: Latest Start (the latest date each task can start to hit target) and Days To Pull-in which is the equivalent number of days to equal the Latest Start date.

  • Make sure to select the “Reset Simulator” button to reset the simulator.

    • For nerds (that’s you Tom!): the simulator puts a Must Finish On date constraint on the Wiggle milestone equal to the date of its Target date. the Reset Simulator ensures it’s removed.

• Improved checking and fixing of Targets

  • Added Show, Set & Clear functions for the Target and Wiggle milestone settings (avoids having to display the Flag1 and Flag2 columns)

• Clean-up now converts tasks with durations not expressed as days into days

• Added option (in fP Options) to select whether the Analyzer automatically removes duplicate dependencies when run. Default is it does.

• Fixed bug where a duplicate dependency would be removed if one of the predecessors had a negative lag but finishing earlier than one of it’s other predecessors. Tasks with negative lag are therefore now ignored.

Update

• Added new functionality to the Import Lookahead Report, to allow the user to ignore not updated tasks. this would then update those tasks updated in the LARR, then those tasks not updated would be caught during the manual update.

• Days Remaining and Predicted Finish Date now shown by default

• Fixed bug in PreFresh Report where highlighted Summary tasks were listed in the Lookahead Report

• Fixed bug where starting “From This Task” would start from the beginning of the schedule and not the selected task

Wigglechart

• Additional notes not added when Wigglechart run on the same day

decisionAccelerator 4.19 Released

General

• Calculate manually added back to the Objectives tab. This is a global “do not calculate flag” so changing the objective’s pair-wise or the alternative’s rankings does not recalculate the objectives or the alternatives. This is primarily used for those with laptops from the Stone Age.

• Fixed bug where the error message “Must be on a model.” would appear, even if on a decision model.

Objectives

• Consistency now turned off during sensitivity analysis

• Fixed problem where sorting the objectives after performing a sensitivity analysis more than two times would cause the original pair-wise judgements to be lost

• Fixed problem when deleting an objective, where selecting an entire row (vs. just the objective’s name) would cause 16,364 cells to be deleted

• Fixed problem where “Calculate pair-wise” remained checked when “Force rank” was unchecked

Alternatives

• Improved representation of bars in the rankings table with only positive and negative values and when “high values are good” and “low values are good”

fastProject 4.8.11 Released

General

• Breakdown

  • Breaking down a task into parallel tasks now links all tasks to the summary’s end milestone

  • Added “Update prefix” to the shortcut menu

  • Milestone name now labeled correctly when breaking down a task with a prefix

• Touchpoints/Checkpoints/Deliverables

  • Inserting a Touchpoint, Checkpoint or Deliverable now copies over the Core Team Member, Activity Owner and Function from the selected task to the Touchpoint

  • Fixed bug where inserting a Touchpoint before a Summary task would likely the Touchpoint to the Summary task. In this case, the Touchpoint is simply not linked.

• Can now “Update” a prefix for tasks. Simply select one or more subtasks within a group with a prefix to add/update the prefix for the selected tasks.

• Milestone Owner renamed to Core Team Member

• Added “FP::completed within date range” filter so allow the user to display all tasks completed within the user-selected date range

• Showing Actions now does not include the Notes column

Update

• PreFresh Report now displays Core Team Member and Notes by default. The notes are empty and allow the person responsible for updating the task to add color to the status update. The notes are imported to the task’s notes and date stamped.

• PreFresh report now shades the Remaining Duration/Finish Date cell yellow (with supporting text) when the Finish Date exceeds a threshold. The default threshold is 30 days, but can be changed through the fastProject Options > Update tab.

• Bug fixed when updating a single task could cause an error if cursor was in the lower pane.

Analyzer

• Added “Show All Excluded Tasks” under the “Analyze” dropdown to show all tasks that have been excluded by the Analyzer

fastProject 4.8.10 Released

General

• Enhanced interface to create Calendars, change calendar working time, define Exceptions (e.g. holidays), Work Weeks, etc.

• Windows now pop-up on the same screen as MS Project when extended display is used

Refresh

• Importing a PreFresh report :

  • Imports the Task name and Activity owner when different.

  • Opens he LAR if there are errors (vs. the user having to open it).

  • Enhanced error checking when entering the status updates through conditional formatting.

  • Notes column now visible. Any notes added by the user are imported to the task’s notes on import.

• Yellow shading representing started tasks that are due to be finished by the next refresh not highlighted in the prefers report (still highlighted in the PostFresh report)

• Near-term critical paths now works on checkpoints with a date constraint in the future

Wigglechart

• Bug fixed when displaying only one target on the 3-on-1 Wigglechart

Effort Update

• Bug fixed where a task’s % Complete was incorrectly flagged as an error when importing effort numbers

• Baseline now automatically set when importing

Analyer

• Fix duplicate links only performed on projects with no inserted projects

• Fixed bug where the Analyzer would crash with inserted projects

Inspector

• Item added to WBS sub-menu to automatically display all near-term tasks (starting within 1 month) with a duration of more than 15 days

fastProject 4.8.9 Released

General

• Link to Last and Link from First functions improved - now works for all scenarios

• Updated “Change working time” functions

Update

• Importing a PreFresh Report now automatically imports the updates using the following rules when no update is provided:

  Tasks

  • All update fields blank then update as not started

  • If started and Finish date is in the past then update with a remaining duration of 1 day

  • If started and Finish date is in the future then update as on schedule

  Milestones

  • Finish date is in the past then update as not finished (reschedule)

  Touchpoints, Checkpoints and Deliverables

  • Finish date is in the future then assume on schedule

• Importing a PreFresh report will automatically invoke an Update immediately after. This is to ensure all tasks get updated, i.e. Update will catch any tasks that were not or need updating.

• PreFresh report now shades the input cells that require response. Invalid responses are shaded red.

• Days Remaining and Predicted Finish Date columns now hidden by default

• In the PreFresh report, entering Days Remaining as a date will now automatically format the cell as a date. Likewise if entering as a duration will automatically format it as a number.

Inspector

• Targets report now omits the start-up window (with options) and simply generates the report. First column is now the Target ‘s ID and Targets ar enow sorted by ID as the default.

• Bug fixed when analyzing the critical path with near-term critical paths only, when the primary critical path hasn’t been updated.

Wigglechart

• Wigglechart 3-on-1 bug fixed when only one data point exists in the Wigglechart.

Analyzer

• 15-20x speed improvement in Delete Duplicate Dependencies

• Clean Up schedule and Delete Duplicate Dependencies functionality now integrated into Analyzer, i.e. performed when running the Analyzer and is now no longer a separate function

Resources

• New feature added “Update Effort” within the Resources tab. Like “Update Progress”, it runs through the schedule, but updates effort (rather than time). Effort can be expressed in days or hours, and can be updated by % Complete or Actual and Remaining. In addition, resources can be allocated to a task from the resource pool. An effort PreFresh report accompanies the effort updater. More detail can be found in the corresponding documentation.

Crystal Ball or Early Warning System?

Have you ever had this happen to your project, where you were on track to finish a major deliverable, then close to the end, the schedule started to slip. The Wigglechart below shows how the team aggressively pulled in the schedule at the beginning, they tracked to the schedule for about 6 months, then things started slipping slowly, then about 2 months from the target they really started slipping week for week.

The fundamental problem is by the time they knew they were going to be late, it was too late to recover. If only they had a crystal ball or some kind of early warning system that told them this was going to happen early on so they had time to correct the problem.

Well, we don’t have a crystal ball but we do have an early warning system. It starts by addressing the causes of why this happens, then implementing solutions so if the schedule slips, you see it early on. Here are just some of the reasons that can cause this to happen, along with corrective solutions.

1. Planning too aggressively at the beginning

   • Problem: Nobody wants to show a late schedule to management, so durations are aggressive and manufactured to show the schedule that finishes on time. Of course, nobody believes the schedule because “we’ve never done it that quickly before”, but if we push hard enough, we’ll try and get it done by then. This is our “target schedule” (though not based on any form of reality).

   • Solution: Show a schedule that’s late! Not intentionally, but rather we want to show a realistic schedule, and if the durations are really unknown, be conservative, not aggressive. If there’s a gap, we want to show it now rather than later. By looking at the critical path (the tasks causing the schedule to finish late), it may cause us to change our overall strategy (buy vs. make, outsource vs. hire, change product definition) that would allow us to realistically finish on time.

2. The schedule is not updated

   • Problem: By default, schedules always want to move to the right and get later. If the schedule is not updated, these slips will accumulate weekly, and at some point, becomes impossible to recover, i.e. the gap is too big to pull-in given the number of days remaining to target.

   • Solution: Refresh (update & pull-in) the schedule weekly (minimum). If the schedule slips, attempt to recover the slip (we’ve seen teams not leave the room until they’ve figured out how to get the lost time back). We usually push teams to get a further pull-in. This is called “banking time”, so if the schedule slips later, we have that buffer to minimize the impact on the schedule. This is a proactive rather than a reactive approach. Pulling in before the schedule slips.

3. Updating long duration actives

   • Problem: If I’m managing a multi-week or even multi-month activity, and I slip the schedule (assuming I even know it), I know I have time to recover, so I will report on schedule. This scenario is very similar to point #2 - I will report being on schedule until the last possible moment when I know the finish date will be impossible to hit, and then I have to report it.

   • Solution: Breakdown the near-term asks (looking out about 4-6 weeks) into 1-5 day duration. If a task doesn’t finish on time, I will see the impact on the overall schedule. If the schedule slips, I have enough detail to determine how to pull the schedule back in (if I’m only looking at a 90 day task, I can’t see the detail or see the subtasks driving that end date, so I can’t pull it in).

4. Missing tasks

   • Problem: the activity owners have not been involved in either the initial planning or/and the schedule hasn’t been continuously scrubbed. We all know work changes over time, and the more a team learns about the project, the more the work will change. However, if the changes are not entered into the schedule and tracked, we will not be able to see the impact of those tasks on the schedule. If they would end up on the critical path (but we can’t see them), then we could end up focusing on the wrong tasks. This is a double-whammy, because since the work is not in the schedule, it is not updated and therefore we se the same effect as point #2.

   • Solution: The activity owners should be involved in defining their schedule. The schedule should be continuously scrubbed throughput the week, so as the project and work changes, so does the schedule.

5. You just don’t know how long the work will take

   • Problem: You don’t know how long the work will take, since experiment #2 depends on experiment #1, experiment #3 depends on experiment #2, and so on. So the schedule is planned assuming one experiment (right first time), and if it doesn’t work, you will just re-plan.

   • Solution: Estimate how many learning cycles (experiments) are needed (realistically/conservatively), determine the duration of each learning cycle, and plan accordingly. We have a rule of thumb that easy problems (we’ve done this before and there’s a large amount of reuse) usually need 1-3 learning cycles, medium problems (we’ve done this before but there are a lot of changes) are usually 3-5 learning cycles, and hard problems (we’ve never done this before) are 5-7 learning cycles. The team usually knows whether it’s an easy, medium or hard problem.

6. Lying - or not telling the truth

   • Problem: If I’m managing my part of the program and the schedule slips, I may not want to report the slip (as this is “bad”), in which case, I will report “on time” and hope I will make it. Again, I don’t see the slips early and they accumulate until at some point I go past the point of no return and to becomes impossible to recover.

   • Solution: Education and training. It is important all team members understand that we are looking for honesty and transparency, Nobody will get “beat up” if a slip is reported, but the focus becomes finding a solution to recover from the slip. Breaking down the near-term, long duration tasks into 1-5 day duration will go a long way, since activity owners will have to report back each week whether they completed the task.

There are many other reasons why the schedule can appear “on time” until the end and then slips, but these are the main ones. To implement these solutions requires both training and coaching a project team.

Schedule pull-in makes the Refresh Planning process work

Refresh Planning is made up of the following elements:

• Update (looking back to record what was done)

• Pull-in (looking forward to breakdown long duration tasks and/or change the schedule to cause schedule acceleration)

Most teams only focus on Update, which is good, but it alone does not cause the schedule to accelerate. You really need to do schedule pull-in after each update.

Reserve 5-10 minutes at the end of the refresh session to seriously look for pull-in opportunities and then put them directly into the schedule so the team can see the result of the action.

You can aid this process by asking:

1. What is on the critical path over the next 3 weeks?

2. Looking at the critical path chain of activities, what can we do to accelerate this work?

3. Specifically, can X be done at the same time as Y? Can we do Z faster in any way? Can Q be broken down into more detail and made to go faster?

4. Finally, if all the above fails to generate a pull-in, ask if the work over the next three weeks can be done differently in order to make it go faster?

5. If you get a pull-in, ask what the risks are with the new flow and what you can do to help mitigate them?