A Post-Mortem on the Unsuccessful MES Project You Are About to Start: Part 4
- GPA
- Oct 30
- 9 min read
Updated: 2 days ago
Project Billing: Fixed-Price Versus Time and Materials
Project billing is a complex topic with two distinct perspectives: the customer and the vendor. The vendor’s goal is to maintain profitability to sustain operations, while the customer seeks to maximize return on investment (ROI) to support continued growth. Balancing these priorities can be challenging but achievable. To focus on project impact rather than financial debate, this discussion centers on how billing structures influence project outcomes. A successful project depends on selecting a billing method that works for both parties, while also ensuring the presence of other critical success factors such as engaged stakeholders, organizational buy-in, and well-defined requirements. Without these elements, even the most suitable billing model is unlikely to produce a successful outcome. Although a project may still succeed under less-than-ideal conditions, the likelihood of success is significantly reduced without careful attention to all contributing factors.
The most common billing type for a project is the Fixed-Price model. As the name suggests, the project has an overall price quoted within the proposal. This price is based on detailed and comprehensive requirements established through discussions with the customer (as described in Part 1 of this series). Development and commissioning costs are specified in the proposal and reference all expected deliverables, though in many cases, commissioning costs are separated as Time and Materials (T&M). Below are some common pros and cons of this approach:
Pros
Predictability – Customer knows what the full project is going to cost, making it easier to justify and budget for.
Simplified Invoicing – Based on payment schedule set during the sales cycle.
Cons
Scope Creep – It’s common for new features/functions to be requested by the customer during a project as they start recognizing the platform’s power. Though a great indication of engagement, these additions can be difficult to implement as part of a fixed-price project.
Extensive Upfront Planning – Complete and approved requirements are critical to generate an accurate estimate for the full scale of work to be delivered.
The issue of scope creep often becomes a point of contention during the development phase of a project. It is important to establish a plan before project execution to ensure both teams are aligned on expectations. The most common pitfall occurs when small, seemingly harmless changes are introduced without proper evaluation or approval. To prevent this, a defined process should be followed whenever a scope deviation request is made. The following steps outline best practices for managing such requests:
Always the first step, the requirements for the deviation should be determined and documented
An estimated cost and schedule adjustment is given for additional effort to implement the change
The following actions can then be performed
Change Order – An additional purchase order is provided by the customer to roll the change into the current project. Typically, the most direct action when additional scope is created.
Function Replacement – A lesser critical function is dropped from the project and replaced with the new requirement. This can be challenging to select the function to deprioritize to ensure the lost/gained efforts are balanced. This can also create buy-in issues for those that championed the feature to be replaced.
New Function Shelved – The addition is shelved and prioritized as part of a later project. This is also straightforward as there is no impact on the current project, but the new requirement can be pushed months into the future, again potentially creating conflict within the stakeholder team.
The next type of project billing to consider is Time and Materials (T&M). This model, while largely self-explanatory, represents the opposite end of the spectrum from the Fixed-Price approach.
In this model, hourly rate tables are used to invoice costs for development, design, and management tasks without fixed budgetary constraints beyond the approved purchase order amount. This type of billing aligns more closely with an Agile structure than with traditional Waterfall development. In an Agile-executed project, features are broadly defined at the outset, followed by cyclical development periods—typically one to four weeks in duration. Two-week sprints are often considered an effective length, as they allow for consistent progress while maintaining flexibility. Following Agile methodology, each sprint generally produces updates to the code that can be implemented incrementally, though in practice this process is sometimes adapted to fit project needs. Below are some common pros and cons associated with Time and Materials (T&M) billing:
Pros
Flexibility - Changes in project scope and unexpected issues can be accommodated more readily.
Transparency - Billing is at actual costs incurred, providing a clear understanding of expenditures.
Cons
Budget Uncertainty - It's nearly impossible to predict the final solution cost making ROI justification difficult for a manufacturing company where income is based on profit per produced part.
Incentivizes Slower Work - Without a guiding schedule, tasks can take longer, not because of dishonesty, but without defined urgency, developers tend to over-deliver functionality. This is another reason why Agile development is important for T&M projects.
Requires Stringent Time Tracking - Accurate time and materials tracking is critical for each billing cycle.
Timeline Extension - As additional scope is introduced, as is characteristic of this method, the completion date continues to be pushed out, sometimes by months. This also can be a consequence of the slower development work.
The final project billing model to consider is Milestone-Based Billing. This approach is similar to the Fixed-Price model, but invoices are triggered by predefined feature milestones rather than by reaching percentage-based thresholds. While closely related, this model introduces distinct advantages and disadvantages. As with Fixed-Price projects, requirements and features must be thoroughly documented, and project execution should align closely with these specifications. Agile methodology is typically the preferred approach, as it supports incremental progress and clear checkpoints. Focus remains on one feature at a time, resulting in a structured, step-by-step progression toward the final solution. Pros and cons of this approach include:
Pros
Predictable Income and Cash Flow - The billing for each feature has already been established so is more consistent and predictable.
Motivation for Completion - Triggering invoices by feature delivery (obviously) provides an incentive for the vendor to complete features as rapidly as possible.
Cons
Requires More Project Planning - Milestones and payment schedules must be clearly defined and planned for.
Can be Less Flexible - Since a feature has an established cost based on the initial requirements, scope changes are less likely to be rolled out.
Potential for Dispute – Without a concise definition of "Done", each milestone could be met with disagreement as to the complete status.
So, what does all this mean for an MES project that is about to begin?
Under the right conditions—when the project has been properly prepared following the considerations outlined in this white paper series—any of these billing methods can be successfully implemented. A modified version of the milestone approach often provides the best balance. The project proposal includes a fixed price for well-defined features and goals, with invoicing tied to documented feature milestones. Using a Time and Materials (T&M) structure for commissioning adds flexibility to handle any unforeseen time extensions. This combination delivers an accurate project cost foundation for ROI justification and establishes a reliable schedule. The “fairly” aspect comes into play with the addition of a contingency fund, typically 2–5% of the development cost.
The reasoning behind this recommendation is that nearly every project experiences at least one “eureka moment,” when stakeholders identify enhancements or additions that would add value to the final solution. In a Time and Materials (T&M) project, this is less of an issue, as the effort can simply be extended to include the new work. Regardless of the billing strategy, however, any scope change should be properly evaluated, with the additional effort proposed and approved—avoiding “blank check” funding, which rarely leaves all parties satisfied. In a traditional fixed-cost project, such additions would result in a change order or reallocation of features. With a contingency fund in place, decisions about additional scope can be made more efficiently, with one fewer variable—how to finance the change.
This approach streamlines the process, allowing for limited scope adjustments while keeping them within a fixed budget. Once the contingency fund is depleted, or a change exceeds the available amount, additional considerations must be made, such as replenishing the funds. Any unused portion of the contingency fund at the end of the project remains with the customer.
Project Schedule: Strategic Alignment'
The project schedule is often one of the most contentious aspects of execution. This challenge is less prevalent in Time and Materials (T&M) projects, which typically do not operate under a fixed timeline or a predefined definition of completion. In many cases, however, a common scenario occurs: the sales cycle concludes, and the customer receives the project proposal. Due to internal approval gates and other delays, several months may pass before the purchase order is issued. Despite this delay, the final project deadline remains unchanged, resulting in a compressed development phase.
As one would expect, this can be mitigated somewhat with additional developers. There are several potential issues that arise from this. First, developer productivity does not follow a 1:1 ratio with added resources. This means that doubling developers isn’t twice as effective in generating code. Additional project and technical management overhead and the extra team coordination slightly reduces efficiency resulting in something closer to 1:0.85 ratio that decreases as the development team grows. Adding extra resources to counter-act schedule compression may result in a surcharge from the vendor. Depending on the vendor, current project load, and required skills, additional developers simply may not be available to bring into the project.
Of course, most vendors (GPA included) will do their best to accommodate the tighter schedule, especially when there are extenuating factors such as unexpected supply chain delays. However, it’s up to the stakeholders to plan for known or probable delays to the project kickoff as well as those experienced during development. To help alleviate the impact of delays, make sure executive sponsors are aware of potential schedule impacts when blockers are encountered, both during the sales phase and the development phase. If a document review or demo feedback is to be completed within a given timeframe, make sure those involved are informed of the deadline and the importance of adherence. Some advice on stress relief, arranging a top tier executive walk-through a week after the projected completion date (especially weeks or months in advance) can put unnecessary stress on the stakeholders and development teams. As I’ve stated, most MES projects can be complex with unforeseen delays. Not accounting for this can impact the real and perceived success of the project.
Project management is a critical key to creating and adhering to a schedule. Of course, all bets are off with T&M as, by design, they don’t work against a fixed schedule nor a generic definition of done. My suggestions are directed toward either standard or my variation on a fixed-price project. There are some variations and separation of responsibilities (especially in the case of Agile-centric development teams), but the typical development team is comprised of:
Project Manager - Aligns project with budget and schedule expectations.
Product Owner - Translates the project requirements into development backlog tasks.
Technical Lead – Oversees the development team and assists with technical challenges. Based on the vendor’s organizational preference, the Product Owner and the Technical Lead may be the same person.
Quality Assurance - Works to minimize released non-conformances (bugs).
Developer - Depending on project scope and budget, between one and six of various experience levels and skills.
At the beginning of the development phase, the project manager works with the technical lead to reference the requirements and project effort estimation to create a realistic project timeline with consideration to the complexity of the project, available number of developers with the prerequisite skills, and any encompassed holidays. A rough (emphasis on rough) estimate of the project duration can be part of the proposal, typically within a month or so, but it’s seldom detailed to the level it will be once this analysis takes place.
The project manager further enhances the timeline with feature milestones. Dependencies are clearly defined (i.e., delays in a dependency completion date are likely to impact the overall project completion date). A good example of this would be access to the production environment for final QA testing and commissioning of the core solution (or MVP if preferred). If the associated tasks are scheduled for three weeks and access is delayed by two weeks and four days, the tasks are unlikely to be completed in one day. This may seem like an obvious cause and effect, but it is a scenario that occurs frequently in practice, even if this example is somewhat exaggerated for emphasis.
It’s advisable to add some buffer times for dependencies with an assigned risk factor (such as there is another project running concurrently that may result in sporadic availability of the support team). Project managers with management experience in MES projects have intuition on areas to buffer.
The proposed timeline is shared and reviewed with the responsible stakeholder(s) to address any concerns or insights from their perspective. Once the timeline is approved, the project manager will work with the technical lead to maintain the schedule as closely as possible with regular update meetings to discuss the status with the stakeholders. Any deviations are quickly documented and shared with the stakeholders along with reason(s) for the unplanned delay and mitigating strategies to avoid any future reoccurrence.
With an Agile-style development process and a solid schedule for this phase of the project, a productive and collaborative partnership becomes much easier to foster thereby promoting a higher probability of a successful outcome. Regular cadence status meetings between the vendor and the stakeholders, especially the product owner(s), following the progress against the expected timeline is a powerful tool in keeping the project on track with a high level of transparency.
Coming Next: Part 5
Part 5 of this series concludes A Post-Mortem on the Unsuccessful MES Project You Are About to Start by examining three final factors that shape MES success: system access, platform selection, and execution methodology.
This final installment connects lessons from earlier parts, demonstrating how the right tools, secure access, and development approach—whether Waterfall or Agile—influence project outcomes. It closes with key takeaways to help organizations plan, execute, and sustain their digital transformation journeys with confidence.
