project management

Understanding the As Late As Possible (ALAP) Scheduling Option in Practical Terms

, , , , , , , , , ,
Understanding the As Late As Possible Scheduling Option in Practical Terms

Many project professionals have spent entire careers without ever using the As Late As Possible (ALAP) scheduling option, although the underlying idea feels familiar. Why? Because it’s very similar to the “just-in-time” concept widely used in manufacturing and logistics.

In materials management, just-in-time means having what you need arrive exactly when you need it, minimizing storage costs and reducing inventory. The same principle can apply to project labor, but with some important cautions.

The “Right Time” for Project Work

On development or design projects, doing work too early can be counterproductive. If designs change, early work may become obsolete, forcing costly rework. The “right time” to perform a task is often determined by schedule logic. In some cases, however, it can also be guided by the ALAP constraint.

Before we explore when ALAP makes sense, let’s quickly review the two primary constraint options in Microsoft Project (and most other scheduling tools).

ASAP – As Soon As Possible

As soon as possible:

  • Is the default setting for forward-scheduled projects (when you set a project start date).
  • Means tasks are pushed as early as possible, immediately after their predecessors finish.
  • Is ideal when you want the earliest possible completion and clear visibility into float/slack.

In an ASAP chain, every task begins at the earliest opportunity, pushing resources as far to the left as possible on the Gantt chart as illustrated in Figure 1.

Figure 1: As Soon As Possible Scheduling Option
Figure 1: As Soon As Possible Scheduling Option

ALAP – As Late As Possible

As late as possible:

  • Means tasks are scheduled as late as possible without delaying the successor or project finish date.
  • Is used in backward-scheduled projects (those planned from a fixed finish date) or when you want to defer work until the last responsible moment.
  • Microsoft Project automatically places each task at the latest feasible start date that still satisfies all constraints.

Switching a chain of tasks to 100% ALAP dramatically shifts all work to the right on the timeline as illustrated in Figure 2. The impact on management is significant: Every task now has zero total slack, which means any delay, even one day, directly delays the project finish. Multiple paths can appear “critical,” making control and reporting more complex.

Figure 2: As Late As Possible Scheduling Option
Figure 2: As Late As Possible Scheduling Option

When ALAP Makes Sense

There are legitimate reasons to use ALAP selectively. For example:

  • When a task consumes resources you don’t want engaged early (e.g., expensive equipment rental or specialized consultants).
  • For just-in-time deliveries or procurements where early completion has no benefit.
  • When modeling backward scheduling. For instance, working from a fixed delivery date toward today.
  • A mixed schedule. Mostly ASAP but with a few ALAP tasks can balance flexibility, cost control, and realism as illustrated in Figure 3.
Figure 3: A Schedule Using ALAP and ASAP
Figure 3: A Schedule Using ALAP and ASAP

A Real-World Example

One of H&A’s senior scheduling consultants once faced this exact dilemma while helping to prepare a multi-year, multi-billion-dollar defense proposal for a project with strict annual funding limits. 

With less than two weeks before the submission deadline, the Proposal Director was exasperated: “I keep asking the engineers what can be delayed! Why does everything have to happen up front? The front-loaded schedule is blowing our funding cap!”

A quick inspection revealed the problem: every task was set to ASAP. The entire effort was jammed toward the beginning of the timeline, creating a massive early demand for resources. After several failed attempts to persuade the engineers to move work later, the consultant proposed something unconventional: “Let’s flip the question. Instead of asking what can we delay, let’s ask what must be done now.”

The H&A scheduling consultant converted the entire schedule to ALAP, instantly shifting all work to the far right of the timeline. The resulting view inverted the problem, from overspending early to under-spending, and gave the team a new way to discuss priorities.

In meetings, engineers were asked to move tasks from ALAP to ASAP one at a time, stopping when the annual funding limit was reached. The discussion changed from “Why can’t we do this now?” to “What can we afford to do this year?”

The result wasn’t elegant, but it solved the immediate problem: the funding limits were clearly observed, the resource profile became manageable, and the trade-offs were visible to everyone.

How ALAP Affects Critical Path and Risk

Because ALAP tasks consume all available float, they appear critical even when they may not truly drive the project finish. This can obscure the actual critical path, making it difficult for project managers to distinguish between genuine schedule risks and artificial ones. In Earned Value Management (EVM) environments, this matters. Earned value metrics depend on knowing which tasks drive completion. Excessive use of ALAP can lead to misleading forecasts and distort DCMA data quality metrics such as the Total Float test and the Critical Path test. For this reason, auditors often recommend using ALAP sparingly and documenting the rationale wherever it’s applied. 

Note: in a sophisticated scheduling environment, it is possible to make a copy of the integrated master schedule (IMS) and revert to ASAP to look for critical paths in the normal sense.  

Combining ALAP with Other Constraints

In practice, project managers often use a blend of constraint types. For example, you can combine ALAP with “Must Finish On” or “Start No Earlier Than” dates to simulate external dependencies such as contract milestones, funding release dates, or material delivery windows. This hybrid approach allows the schedule to model reality while maintaining logical control. However, it’s important to track these constraints carefully. Too many “hard” constraints of any type can reduce the schedule’s dynamic nature and make automated forecasting less accurate.

Guidance from Industry and Agencies

Industry and government scheduling guides consistently advise restraint when using ALAP. The DCMA data quality tests consider the presence of ALAP tasks as a potential red flag because they can mask schedule float and obscure the true drivers of program completion. Similarly, the GAO’s Schedule Assessment Guide recommends minimizing artificial constraints and using logic-driven sequencing whenever possible. ALAP may be appropriate for modeling constrained resources or fixed delivery milestones, but it should always be justified and documented. Within DoD and NASA programs, reviewers often require clear evidence that ALAP usage is intentional, controlled, and limited to well-understood modeling cases. It should never be used as a workaround for poor sequencing.

Key Takeaways

  • ASAP emphasizes early starts, clear float visibility, and traditional forward scheduling.
  • ALAP emphasizes delayed starts, tighter resource control, and is useful in backward or funding-constrained planning.
  • Use ALAP sparingly and intentionally as it can obscure float and create multiple critical paths.
  • In creative problem-solving, toggling between ASAP and ALAP can reveal insights about timing, funding, and necessity that might otherwise remain hidden.

Final Thoughts

The ALAP constraint is a powerful but double-edged tool. It can simplify discussions about funding limits, resource phasing, and timing priorities, but it also carries risk if used indiscriminately. Like most features in commercial off the shelf (COTS) scheduling tools, its value depends on the user’s intent and discipline. The best project schedules blend logic, transparency, and flexibility. Understanding when to use ALAP (and when not to) can make the difference between a reactive plan and a truly managed one.

Interested in Learning How to Use More Advanced Scheduling Techniques?

Master schedulers skilled at asking the right questions to solve project management challenges hone their craft based on years of experience and working with other scheduling experts. There are always opportunities to learn more. H&A routinely offers basic, advanced, and tailored scheduling workshops taught by senior master schedulers with decades of experience in all types of project environments using common scheduling tools such as Microsoft Project and Oracle Primavera P6. Give us a call today to get started. 

Humphreys and Associates also offers basic and advanced EVMS training as well as tailored EVMS training that aligns with a client’s EVM System Description. 

Understanding the As Late As Possible (ALAP) Scheduling Option in Practical Terms Read Post »

EVMS and Agile Implementation FAQ’s

, , , , , , , , , ,
Title Image - EVMS and Agile Implementation FAQs

These are some of the frequently asked questions we receive when discussing EVMS and Agile implementations within the same company or on the same project. 

Question 1: What documentation do you have that I can use to help me understand EVMS and Agile and how they are implemented?

Answer 1: There is expansive EVMS documentation, and the EVMS guidelines are well documented. On the other hand, there is little in the way of Agile documentation since the Agile mindset is to be lean and not to document unless absolutely necessary. The DOD released an
EVMS and Agile Program Manager’s Desk Guide that can be used for quick reference. H&A has done the homework and has created training for EVMS and Agile.



Question 2
: What is the comparable Agile term or artifact for this EVMS artifact (for example the WBS)?

Answer 2: There is no roadmap between EVMS and Agile that is hard and fast. The best approach would be to identify “similar to” situations or likenesses. For example the EVMS WBS is similar to the Product Backlog within Agile. The Steering Committee of The World Congress in Computer Science, Computer Engineering and Applied Computing reported on Constructs to Support Agile and EVMS



Question 3
: What roles within the PMO are there for EVMS and for Agile and how do they relate?

Answer 3: In Agile there is no real “management” role. So the PMO roles that are management titled are not germane to Agile. And in the opposite direction, the Agile roles do not really exist within EVMS. For example the Agile “Product Owner” is a person with a customer view of the product and speaks for the customer. In a stretch this could be a high level Software or System Engineer with requirements responsibilities. The Scrum Master is a facilitator on the Scrum team and there is no corresponding EVMS role. The team members organize themselves so there is no team lead like the Control Account manager in an EVM System.



Question 4
: Since the Sprint in the Agile/Scrum approach is defined as a time-box with a fixed end date, how do you reconcile that with the EVMS approach of working the task until it is done?

Answer 4: The EVMS baseline can be set above the Sprint level and can correspond to known “mandatory” delivery points such as release deliveries. This will then align the Agile deliveries to the EVMS structure and the two can work together.


Question 5: Does the fact that Agile/Scrum Sprints have very short durations cause a problem with EVMS performance measurement?

Answer 5: Not at all since teams update their progress daily. But it is preferable if the Sprints are four weeks or less and align with the cut-off dates for the EVMS. In that way the EVMS can pull the stated performance from the teams and use it as the input for the EVMS without any translation work. If a Sprint crosses an EVMS period, that would need special consideration.


Question 6: Since Agile work is not really budgeted, how does that reconcile with the EVMS need for budgets and budget control?

Answer 6: Budgets will be held in packages in the EVMS based on the plan for the Sprints and the teams doing the Sprints. The Agile weighting of work will be within the same packages but is not considered to be budgeting; it is weighting of milestones, if anything.


Question 7: We do not like the idea of the 0/100 EV Technique even with milestones. At our company we have an allowance to earn partial credit for milestone work. How does that fit into the EVMS and Agile implementations?

Answer 7: Agile wants to measure work when done. The work should be in such small stories, or tasks, that they are in-process for only a matter of days. Partial credit should not be needed in this situation; if it is, then perhaps there are issues with work definition.


Question 8: Agile applies to software development, but can we use it for other types of work?

Answer 8: Yes. It is a misconception that Agile is for software only. If you are creative you can find ways to use Agile Development in many areas. One company reports it uses it for circuit design and breadboarding resulting in significant time savings. 

For additional information about EVMS and Agile see the blog post: 

Agile/Scrum Ceremonies and Metrics Useful in EVMS Variance Analysis and Corrective Action

EVMS and Agile Implementation FAQ’s Read Post »

EVM (Earned Value Management) vs. Agile Project Management

, , , , , , , , , , , , ,

This article provides an introduction to the differences between an Earned Value Management System (EVMS) and Agile approaches on projects, and isolates the challenges of implementing an EVMS on a project where the project management has chosen to follow an Agile approach to the development work. The article explores the principles of EVMS and of Agile, and contrasts them to show where there are inherent conflicts. The article then discusses how the conflicts can be mitigated so that the benefits of both the EVMS and Agile can be obtained from a joint implementation.

Controlled Planning with EVMS

Controlled Planning with EVMS

Earned Value Management (EVM) Background

Earned Value Management is a 50 +/- year old methodology based on widely accepted principles that applies documented, systematized practices to support the processes of organizing, planning, directing, and controlling large complex projects, of any nature, which contain a high degree of uncertainty.

An EVMS is structured compliant to 32 guidelines that define what a project management information system should be capable of doing to support the program management team. Within the 32 guidelines there is a subset of generally recognized core principles. The core principles are:

  1. Organize the entire scope of the project using a Work Breakdown Structure (WBS).
  2. Organize the project team using an Organization Breakdown Structure (OBS).
  3. Integrate the project work with the project team to create management control points (Control Accounts).
  4. Schedule the project work in the Control Accounts across the entire project duration at the appropriate level of detail.
  5. Establish time-phased budgets for the scheduled work in the Control Accounts.
  6. Establish the scope/schedule/budget baseline as the Performance Measurement Baseline (PMB).
  7. Authorize the scope/schedule/budget and control the start/stop of work.
  8. Periodically measure the schedule and the value of completed work and determine the Earned Value.
  9. Record direct costs (actual costs) and summarize into the Control Accounts.
  10. Compare planned, accomplished, and spent to analyze the performance and associated variances.
  11. Develop realistic time and cost estimates for the remaining effort in the Control Accounts.
  12. Rigorously control changes to the Performance Measurement Baseline.

The EVM concept presented in these guidelines is a sound management approach, that once incorporated on any type of program, whether research and development, construction, production, etc. provides all levels of management with early visibility into cost and schedule problems.  Earned Value Management now appears as a contractual requirement on programs world-wide.  Primary EVM users include the United States, Europe, England, Canada, Australia, China, and Japan. It is a requirement of many U.S. Government agencies, including the Department of Defense (DoD), the National Aeronautics and Space Administration (NASA), the Department of Energy (DOE), the Intelligence Community, the Department of Homeland Security (DHS), the Federal Aviation Administration (FAA), the Department of Transportation (DOT), Health and Human Services (HHS), and others.

EVMS has been adopted by companies in situations where it is not a contractual requirement so that they can gain the discipline and benefits of the structural management approach discussed in the guidelines.

 

evms 2

Flexible Planning with Agile

Agile Background

Agile is a 20 +/- year old approach to applying a mindset that values the use of small, empowered, self-organizing, multi-functional teams, mainly in software development, to establish a test driven product development effort. This uses a series of short, rapid incremental builds within projects with a high degree of uncertainty to achieve shorter development times, lower costs, and products more closely aligned with customer requirements.

Agile does not usually appear as a contractual requirement. The concept is adopted by companies and organizations with the belief that a better product will be produced faster, and with less expense, using this approach than if traditional approaches were followed.

There are a core set of principles for Agile that were initially established in the copyrighted Agile Manifesto. These delineated core principles are:

  1. Early and continuous product delivery.
  2. Deliver working software (product) frequently.
  3. Expect change and respond positively to change.
  4. Developers and project business organization (PMO) work together.
  5. Product-focused build teams are at the core.
  6. Support self-organizing teams – trust among peers.
  7. Encourage face-to-face discussions (involve the user/customer).
  8. Working software is the measure of progress.
  9. Maintain a constant sustainable pace of development.
  10. Simplify the process and the product.
  11. Put the highest value on technical excellence.
  12. Improve team effectivity.

So How Does Agile Work?

The Agile mindset or approach is implemented through a process of defining the product backlog into smaller and smaller subsets of work that are structured in a top down fashion. At the lowest level of product backlog, the work elements or requirements can be prioritized and assigned to teams. The self-organizing teams pull work from the backlog and work the tasks to completion in a series of short, time-fixed Sprints or iterations. Sprints are often from 2 to 4 weeks long.

Because the teams are self-organizing, there is no team manager or team lead. The teams work as a group and only pull from the backlog at the last possible minute, and do minimal planning for each Sprint. If the product backlog is properly deconstructed and defined into user stories, then the planning meeting for an entire 4 week Sprint can be accomplished in a few hours.

The teams design, code, test, integrate, and deliver functionality in every Sprint. Since tested product is output every few weeks, all on the project can see the product being created and can contribute along the timeline, as needed, to provide a complete finished product.

The product owner embodies the customer’s perspective and either accepts or rejects the team’s work.  At the latter point of each Sprint, the tested product is demonstrated to the product owner.

High Level Side-by-Side

The two approaches are contrasted in the chart shown below. The EVMS is a methodology that is highly documented and highly systematized, while Agile is just the opposite. It is more of a mindset than a methodology with the preference not to have significant process documentation.

The EVMS is applied to entire projects and contracts, while generally Agile is applied to software portions of projects.  However, it could also be used on other development work.

The EVMS is usually a contractual requirement with significant implementation and operation constraints while Agile has none of these. As a contractual requirement, the EVMS carries with it the option for customer reviews and the threat of non-compliance, which entails penalties.

EVM Agile
Methodology Mindset
Documented Self-defined
Systematized Self-defined
Any type of project Software development (mainly)
High degree of uncertainty High degree of uncertainty
Applied to the entire project Applied to portions of the project
Often a contractual requirement Adopted not required

Lower Level Side-by-Side

In addition to the high level side-by-side, there are significant differences within the details of the two approaches. These are shown in the side-by-side table below.

Agile EVMS
Minimal documentation More documentation
Plan at last moment Plan ahead to end of project
Scope is flexible Scope is baselined and controlled
Expect and embrace change Avoid and/or control change
Schedule (Sprint) is fixed.  Timebox ends the Sprint. End the package when the work is done.
Budget is secondary Budget is baselined and controlled
Cost collection is not mentioned. Cost collection at the right level is critical

Accommodate and Capitalize on Differences

It is possible to implement Agile along with an EVMS if the EVMS application is set up to accommodate the differences and capitalize on them.

For example, the main reason that Agile’s embrace of change is a potential problem within an EVMS is because often the EVMS is used to plan too far in advance, and then reacting to change is difficult and expensive. If short term planning in the EVMS can be coordinated with the Agile planning, then the two can coexist.

The Agile free acceptance of scope changes within the backlog runs counter to the EVMS imposition of baseline change control. But if the EVMS baseline can be carefully set at a work level above the busy lowest level ups and downs, the impact to baseline change control is manageable.

A surprising chance to capitalize on Agile, within the EVMS, is found in the Scrum team approach in Agile where the team breaks work down into tasks far below what would normally be done in an EVMS, and then meets daily to update progress and provide corrective action. This low level constant attention means that the EVMS benefits from a better look at real progress as assessed by the real performers.

Not all the compromise needs be on the EVMS side of the equation. The Scrum team operations will often be defined to have the least possible recording of what happens during the Sprint. Since the product is king, then only the product really matters. But that misses the opportunities to capture the actions of the team for analysis, and use in upgrading their skills later. Necessary compromises would include some additional recording of the daily actions of the team and capturing the progress and problems. These would then be used in the EVMS functions of performance measurement, variance analysis, and corrective action planning.

One other compromise in the Agile realm that would be needed is the adoption of some minimum documentation of processes so that team operations can be repeatable and stable. Even a self-organizing team cannot change the way they work every time it wishes. That would raise the risk of a chaotic work environment.

These topics are recapped in the table below.

Agile EVMS Accommodation
Scope is flexible Select a higher level package for the baseline
Change is expected and embraced Have the shortest possible planning horizon
Plan at the last possible minute Have the shortest possible planning horizon
Daily Scrum Stand-up Meeting Collect the data and use it for performance measurement
Sprint Review Meeting Use for periodic measurement and analysis
Sprint Retrospective Meeting Use in Corrective Action Plans
Lack of documentation Add minimum documentation to stabilize team operations

Bottom Line

Implementing an EVMS is a challenge itself. Implementing Agile is a challenge too; perhaps a more difficult challenge. Implementing the two approaches side-by-side can seem impossible. But it is possible and even beneficial if done in a way the makes needed accommodations in both arenas for the project’s benefit.

EVM (Earned Value Management) vs. Agile Project Management Read Post »

Humphreys & Associates Joins Project Management Institute’s Registered Consultant Program

, , , ,

Humphreys & Associates Joins Project Management Institute’s Registered Consultant Program

Online Project Management resource helps organizations connect with consulting firms

IRVINE, Jan. 09, 2015 — Humphreys & Associates today announces that it has joined the Project Management Institute’s (PMI) Registered Consultant Program, an online resource that provides organizations with the convenience of accessing a PMI-maintained list of consulting firms that are able to improve their project, program and portfolio management practices.

As more organizations adopt project management as a strategic competency for achieving business results, many are seeking the advice of consultants to enhance their project management capabilities. The PMI Consultant Registry is complimentary to organizations, as is the PMI-developed A Guide on How to Select a Project Management Consultant.

The guide walks organizations through the necessary steps to best identify a consultancy that meets their requirements. Each firm listed in the directory provides one case study per area of expertise that highlights its previous consulting engagements.This feature gives organizations insight into the consultancy’s engagement style and its ability to meet the unique needs of a project.

Humphreys & Associates’ project management consultants have worked with all branches of the U.S. Department of Defense (DoD), the Department of Energy (DOE), NASA, other U.S. government agencies, and with foreign governments. “Our associates and teams have great admiration for the Project Management Institute’s global advocacy, education, collaboration, and project management research. As PMI is such a comprehensive resource for project managers Humphreys & Associates therefore is quite pleased to join PMI’s Consultant Registry,” asserted Gary C. Humphreys, President and CEO, Humphreys & Associates.

Humphreys & Associates joins more than 140 consulting companies in more than 35 countries that participate in the Program.

About Humphreys & Associates

Humphreys & Associates, led by Gary Humphreys, is the established leader in earned value management consulting and training. H&A has provided EVMS consulting services to over 850 companies and government agencies worldwide and we have trained over 900,000 individuals at all EVMS functional and management levels.

About Project Management Institute (PMI)
Project Management Institute is the world’s leading not-for-profit professional membership association for the project, program and portfolio management profession.  Founded in 1969, PMI delivers value for more than 2.9 million professionals working in nearly every country in the world through global advocacy, collaboration, education and research. PMI advances careers, improves organizational success and further matures the profession of project management through its globally recognized standards, certifications, resources, tools academic research, publications, professional development courses, and networking opportunities. As part of the PMI family, Human Systems International (HSI) provides organizational assessment and benchmarking services to leading businesses and government, while ProjectManagement.com and ProjectsAtWork.com create online global communities that deliver more resources, better tools, larger networks and broader perspectives. Visit us at www.PMI.org, www.facebook.com/PMInstitute, and on Twitter@PMInstitute.

Humphreys & Associates Joins Project Management Institute’s Registered Consultant Program Read Post »

Scroll to Top