Resource capacity analyzation for Prospect Projects

I follow

Following

We have started to insert an estimted effort into our Blueprints, therefore showing up as Effort in our Ressource Capacity Board. These are average valuves we worked out over the year and depending on the project, we end up fine adjusting them as needed!

We forecast workload by creating dedicated "Effort" tasks. These are the only tasks that include estimated manhours, based on the hours sold for the project.

Each team member receives one effort task per project — we avoid multiple ones to keep reporting clean and manageable. This approach helps us get a clear view of upcoming workload and identify when someone’s at risk of being overloaded, so we can proactively adjust.

We focus on keeping our team’s capacity clear as new opportunities move closer to the pipeline.

We use Wrike to manage all active projects, but for prospects that are near the end of the sales funnel, we don’t create full projects. Instead, we use custom item types or placeholder tasks in a separate folder just for forecasting.

This helps us visualize upcoming workload without cluttering the system. We also tag key team members to get an early sense of bandwidth before things officially kick off.

And..following :)

We add estimated effort to tasks using blueprints, but this effort can be adjusted by the assignee if they are not accurate.

We utilize Wrike's effort estimation features extensively. Blueprints have proven to be our most valuable tool when working within the platform. Having them prepared in advance significantly reduces effort and helps us avoid overestimating or underestimating workloads. While we make adjustments as more specific details become available, the predefined blueprint timelines consistently provide a reliable starting point.

I recommend defining your opportunity stages and any planning triggers to align resource planning efforts with key milestones in the sales process. We use a 6-stage sales process with trigger points in stage 3 for budgeting and 5 (final decision) and 6 (closed-won) for resource planning. When a prospect hits Stage 3 or higher, we create a project in Wrike, and we are actually working on the rolling out the Wrike/Saleforce integration to automate this step for us.

Do you have an excessively large number of prospects? Why are you trying to avoid creating a new project for a prospect?

If you created tasks or projects, you could customize your sales funnel as a workflow. The workflow can then mirror your sales funnel stages. Example: Prospect → Proposal Sent → Negotiation → Verbal Commit → Final Decision → Closed-Won. Use this workflow on a "Sales Opportunities" project folder or a dedicated sales pipeline dashboard. This will let you tie specific planning actions to each stage automatically.

You could also help launch items with automation. Example: When a deal hits 90%, use automation rules to notify your delivery lead, move the project/task from the “Sales Opportunities” folder I mentioned above to “Active” then create a delivery task template (kickoff, scheduling, etc.). This avoids manual handoffs and keeps your teams moving fast.

One other recommendation is to build a dynamic request form for sales to delivery handoff. Create a request form called “Project Forecast Intake” or something along those lines with logic based on deal stage. Include key fields like projected start date, estimated effort (hours or FTEs by role), confidence level or sales stage, and special skill/resource needs. Auto-route responses to a “Resource Planning” folder with proper tagging (e.g., by region or team). This will keep intake structured and enable downstream reporting.

Just a few random ideas. Hope this helps! 👍🏻

We do the same as Florian Gascho and have included estimated durations for each task in our blueprints. 

Also following.

We focus on optimizing our visibility over current active work, so we’re always ready to accommodate new opportunities. We use custom task types and record actual hours spent across different services (content, design, development, strategy, etc). Over time, this gives us solid benchmarks to know how much effort each type of project usually requires.

This is an area we wish to explore more and improve upon.  At the moment we use blueprints with effort assigned and we recommend all new blueprints created to have effort assigned. Some of our teams that work in a sprint style assign effort once they receive their jobs/tickets and this is has been built into their process.  I know some teams have a recurring task set up each Friday for Wrike admin where they look at all their current and upcoming projects/tasks for the next week and ensure effort has been assigned.