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.

Screen Shot 2019-07-30 at 9.33.44 AM.png

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.

How decision model goals & objectives translate to a schedule

How decision model goals & objectives translate to a schedule

In this example the team needed to determine which market segment to target for a new product. The choice of segment would then drive customer selection and eventual product definition around the driving requirements of the tier 1 customer in the selected segment. They believed that 80% of the segment's requirements would be captured from this driving customer, so selection of the right segment and customer was critical to realizing the project goals.

Read More

Criteria versus Objective

Criteria versus Objective

Decision models have three major components; goal, objectives, and alternatives. Some people use "criteria" instead of "objective." There is no "right" or "wrong" term, just different interpretations. When you look at the literature on AHP you find both, for example this good wiki descriptionuses "criterion" and it is hard to find the word objective anywhere. Others only use Objective. The more models we build the more we understand why using "objective" results in better models.

Read More

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?

Horizontal project scoring

Horizontal project scoring

Horizontal project scoring versus vertical prioritization (the zero-sum game). Traditional "project scoring" systems we see look like this... a list of projects in a spreadsheet scored against some sort of measurement criteria. Sometimes the criteria is weighted by importance. Each row (project) is scored against the weighted criteria. The rows are totaled and each project gets a score. Some have called this "horizontal scoring."

Read More

Pairwise ranking of objectives versus simple weighting

Pairwise ranking of objectives versus simple weighting

Traditional "project scoring" systems we see look like this... a list of projects in a spreadsheet scored against some sort of measurement criteria. Sometimes the criteria is weighted by importance. The "weighting of criteria" approach does provide some degree of influence over the project scoring results, but it fails to capture the proportional relationships between criteria or what we like to call "Objectives."

Read More

decisionAccelerator 4.18 Released

General

  • New streamlined ribbon interface

  • Speed improvements

Objectives

  • Pair-wise names now displayed rather than bars

  • Inconsistencies now permanently displayed and visible by a red (most inconsistent) or orange (second most inconsistent) border around the judgement (cell)

    • Note: all current dA models will need to be upgraded to see the inconsistencies

  • Bug fixed where an error would be caused if the pair-wise cell was < -9 or >9. This could caused if the pair-wise was automatically calculated from a force rank.

Alternatives

  • Hiding unused columns now includes columns starting with the word “Column”

Constraints

  • Formatting of the budget on the cost-benefit chart fixed

  • Iterations number displayed when generating a cost-benefit chart now correct

decisionAccelerator 4.17 Released

Alternatives

  • Problem fixed where the bars were shown incorrectly when "Low was set to good”

  • Bars in the ranking table are now split so negative values are represented by a red bar to the left of the zero position and positive values by a blue bar to the right of the zero position. To make it easier to read, the table now has vertical lines marking the boundary of each cell.

Alt ranking with neg numbers.JPG


Cost-Benefit

  • Chart now as a separate file rather than integrated into the dA model. This allows multiple Cost-Benefit charts to be created and, if needed, merged into a single file if different scenarios are being developed.

  • The chart now scales to the number of budget increments/alternatives

  • An “information” screen is now displayed reporting the progress of the creating the cost-benefit chart. This will be particularly useful for charts that take a significant time to create, reassuring the user that it is working.

    • For charts that take a significant amount of time to create, try reducing the number of budget increments

fastProject 4.8.8 Released

General

  • Problem fixed when breaking down a task when the schedule has a blank line (could cause the task to be broken down incorrectly)

  • Restoring Views/Tables/Filters improved and minor bugs fixed

Inspector

  • Bug fixed where the ribbon would disappear in some cases with sub-projectsewfwe

  • Target status now reflects correctly the Target details when the target is in a sub-project

  • Displaying the “Latest baseline” when a target is in a sub-project, now displays the baseline for that sub-project

    • Note: this will also display the same baseline for all sub-projects, so bear in mind that if the sub-projects have not been updated in sync with each other, the baseline displayed for the other sub-projects could be a different date

Update

  • Updating a schedule now automatically displays the Inspector and displays the information relating to the next Target. This allows the team to track changes to the target as the schedule is updated.

Wigglechart

  • Options made clearer when a Wigglechart does not exist

Analyzer

  • Added a check for the fastProject defaults not being set, indicating the schedule should be converted.

decisionAccelerator 4.16 Released

Ratings

  • Improved interface for defining a Values, Values ($) and a Linear scale

Alternatives

  • Bars in the ranking table are now split so negative values are represented by a red bar and positive values by a blue bar. To make it easier to read, the table now has vertical lines marking the boundary of each score.

  • Problem fixed where the bars were shown incorrectly when "Low was set to good”

Cost-Benefit

  • Chart now as a separate file rather than integrated into the dA model. This allows multiple Cost-Benefit charts to be created and, if needed, merged into a single file if different scenarios are being developed.

  • The chart now scales to the number of budget increments/alternatives

  • An “information” screen is now displayed reporting the progress of the creating the cost-benefit chart. This will be particularly useful for charts that take a significant time to create, reassuring the user that it is working.

    • For charts that take a significant amount of time to create, try reducing the number of budget increments

fastProject 4.8.7 Released

General

  • Warning when deleting a Target manually removed

  • Importing a schedule now

    • Sets the split bar up to the Duration column

    • Fits the schedule to the screen

  • Breakdown

    • Can now add prefix to multiple selected summary tasks

    • Bug fixed where breaking down an in-progress activity with a finish date in the past and tasks are not linked would cause an error

    • Doing an Unbreakdown now displays the task bar in the Gantt chart (since it may have been a Summary with the task bards hidden)

  • Updated training files

  • Link to Blog fixed

Refresh

  • After an Update, the Inspector is now automatically invoked

  • Optimized the Refresh interface so the functionality works left to right

  • Bug fixed when trying to run the Wigglechart when the Wigglechart is open. The Wigglechart can be run when open, but only if opened via fastProject, otherwise the user will get a warning to close the Wigglechart.

Macro-micro Roll-up

  • New “Create Macro from Micro” function added. This will delete all subtasks to a roll-up task while moving external dependencies to the associated roll-up task

  • Added an additional test to check for Touchpoints in the macro - these buts be contained within a summary task

  • Updated Macro-micro Roll-up documentation

  • Added a new function “Find duplicate task names” which finds tasks with the same name that can cause problems with the roll-up

  • Added “Display timing analysis” as an option in the initial dialog box

  • Documentation updated (V2.0)

decisionAccelerator 4.15 Released

General

  • Framework sheet updated (and moved to after CostBenefit chart)

  • Risks, PPA and Business Cases moved to separate sheets and Grouping removed

  • Dependency constraints removed

  • Excel tabs now visible when on a regular Excel worksheet - also better handling of other Excel files that are open

Objectives

  • Red “best fit” arrow now just a line to avoid display problems with different screen resolutions

Alternatives

  • Bug fixed where the blue bars were not updated when an alternative was excluded

  • % Rating fixed

  • Slow performance fixed when saving a Custom rating

  • Custom form now dynamically changes size based on the length of the custom name

  • Custom name now highlighted on the form