Project Types

The team operates 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.

Cheat Sheet

• RFC: Request For Change

Project Type Requirements

	Time & Materials	Closed-Scope
Fixed timeline	×	✓
Fixed budget	×	✓
Change requests	RFC	RFC
Explicit client sign-off	×	✓
Backlog (re)prioritization	Flexible*	Strict**

* 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, the team determines 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 (days off and vacation days are not billed).

Benefits

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, the team can adapt to any change necessary to bring the product to success. More than that, 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.

Important Details

Change Management

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.

The team tracks changes via RFCs. In the context of a time & materials project, an RFC doesn’t need to be signed by a representative. It’s solely used for tracking purposes. However, it still must be shared with the client.

Stakeholders Management

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.

Closed-Scope

How it Works

Similar to time & materials projects, the team will assess the project based on all provided materials. Based on this estimation, they determine the optimal team size and composition and the anticipated development timeframe.

Where things differ is that the team makes a lot of assumptions and risk assessments along the estimation way. That’s because:

• They seldom have in-depth and exact project specifications
• 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.

Benefits

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.

Downsides

Risks are high with closed-scope projects. The team commits to a timeline and a budget, while there are usually unknowns when the contract is signed. Also, the team knows that there are always unexpected challenges with every project.

The team does the 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, the team 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.

Important Details

Change Management

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

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

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.

Stakeholders Management

Product Managers must handle closed-scope projects with an iron fist in a velvet glove. The team needs 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.