We operate within two frameworks or project types: open-scope (referred to as “Time & Materials”) and closed-scope. Depending on the project type, the framework to work within will vary widely, especially stakeholder management.
- RFC: Request For Change
Project Type Requirements
|Time & Materials||Closed-Scope|
|Explicit client sign-off||×||✓|
* The backlog can be re-prioritized as soon as the Product Manager raised an RFC and shared via email to the stakeholders.
** The backlog can only be re-prioritized after the Product Manager raised an RFC and the client has signed it.
Time & Materials
How it Works
It starts with estimating the project based on the client’s available material: project brief, designs, API specs, documentation, and everything that can be useful.
Based on this estimation, we determine the optimal team size and composition and the anticipated development timeframe.
The project can then start, and the client is invoiced every month for the number of man-days worked during the month (we do not bill days off and vacation days).
We know that shaping a product is a complicated process. It requires time, feedback (from stakeholders and product users), and adaptability. The time & materials framework encourages clients to build the right product, even if it means changing features along the way.
As the product comes to life, and even more so when the first versions get released to the public, issues and shortcomings will appear. New opportunities will arise as well. User feedback will prove some hypotheses wrong. Data collected will uncover bottlenecks. Market trends will dictate different features.
With a time & materials model, we can adapt to any change necessary to bring the product to success. More than that, our Product Managers will take an active role in identifying areas of improvement and new opportunities. They will continuously re-prioritize the backlog to ensure that the Engineering team tackles the highest value items.
Even though time & materials projects welcome change, it is crucial to keep track of those changes internally and externally (with the stakeholders). It allows the team to view the original product scope and the updated product scope. It also ensures that there is no misalignment with the client.
We track changes via RFCs. In the context of a time & materials project, an RFC doesn’t need to be signed by a representative. We use it is solely for tracking purposes. However, it still must be shared with the client.
While RFCs don’t need to be signed by a representative for time & materials projects, the Product Manager must communicate the impact of a change to their stakeholders. In addition, and even though a signature is not necessary in this case, Product Managers must communicate RFCs in written form:
- Meeting minutes for changes requested during sprint planning (with the client) or other meetings
- Email for change requests that are coming from other sources
If priorities need to be changed (e.g., a feature initially scheduled becomes a lower priority than a change request), the Product Manager must communicate this change to the stakeholders via email.
For time & materials projects, welcome change, but over-communicate about their impact.
How it Works
Similar to time & materials projects, we will assess the project based on all provided materials. Based on this estimation, we determine the optimal team size and composition and the anticipated development timeframe.
Where things differ is that we make a lot of assumptions and risk assessment along the estimation way. That’s because:
- We seldom have in-depth and exact project specifications
- We know that, no matter what, there will be unforeseen challenges along the way
With the assumptions and risks factored in, the estimation results in a much higher number of man-days than in a Time & Materials framework.
The main perceived benefit for clients is that they can plan and allocate their budget with a “final” number of resources and delivery date. This model of engagement, while not the most adapted to complex software development projects, is often the norm in an enterprise context.
Risks are high with closed-scope projects. We commit to a timeline and a budget, while there are usually unknowns when the contract is signed. Also, we know that there are always unexpected challenges with every project.
We do our estimations in good faith. However, if the implementation efforts later appear to be much larger than estimated, or if the client asks for changes that are not part of the original work scope, we will raise a “Request For Change” (RFC).
Managing unknowns requires a lot of proactivity. It demands finding a precise balance between being strict with minor changes while maintaining a positive and helpful attitude.
With closed-scope projects, a client representative must sign all RFCs before the team can start any work.
There are usually two scenarios with changes in closed-scope projects: non-blocking changes and blocking changes.
Non-blocking changes mean that the change requested does not prevent the team from continuing working as planned. For example, the addition of a new feature is a non-blocking change. The team can continue working until the client signs the RFC. Once the client signed the RFC, the Product Manager can work on specs and planning, and the Engineering team can tackle the change.
Blocking changes means that a change, either requested by the client or unplanned but necessary to make progress, prevents the Engineering team from continuing the development work.
This scenario is more challenging as it has a direct impact on the delivery timeline and contractual commitments. In this case, the Product Manager must escalate the issue immediately to the CPO.
Product Managers must handle closed-scope projects with an iron fist in a velvet glove. We need always to be helpful and respectful, but there is no room for flexibility on the project scope given the contract’s nature.
If the client requests something —whether big or small— that’s not in the work scope, an RFC must be raised and signed by the client.
Similarly, if the implementation of a feature in scope appears much more extensive than initially communicated, an RFC needs to be raised.