From Opportunity to Project Scope: Bridging the Gap for Successful Project Delivery

Introduction

Organizations often strive for agility and quick decision-making in the fast-paced business world. In pursuit of these objectives, a common challenge arises – sales personnel taking on some project manager responsibilities at the start of a project. While the intent may be to expedite project initiation and meet customer demands, this practice can lead to significant pitfalls that hinder project success. This article delves into the potential challenges of transitioning from an opportunity to a project.

When is it a Project?

Customer demands and aspirations drive sales teams, while project managers are responsible for delivering the project within defined constraints. The sales folks are close to the customer; the project manager may not have been included in this front end until the project exists. This convergence of interests can often lead to interface and collisions, where the sales group seeks to accommodate customer requests while project managers strive to define the project’s scope and feasible design solution. In this article, we explore the dynamics of this complex relationship and strategies to strike a balance for a successful project outcome.

In the world of project execution, the intersection of sales and project management plays a critical role in defining the project’s scope. The sales personnel are usually the first to explore customer requirements, often articulating the burgeoning scope of the project. From experience, the sales representative often provides budgetary estimates for the project and the scope discussion. Upon acceptance of the offer by the customer, there is often a refinement and more formal articulation of the scope and estimate of cost and schedule. Not always, though.

From Opportunity to Project

The boundary between opportunity and a project is an area for scrutiny. Some companies have this well-designed, perhaps pairing product development competent talent with sales talent during the opportunity period. Doing so imparts the scope to the development team even while in the opportunity stage, but this comes at a cost. For example, what happens if the opportunity never becomes a project? Then the organization has invested time in doing something that is not converting to an income-generating thing. I have worked at larger companies to ensure the heavy inclusion of those key product development talents for larger projects. Sometimes the relationship is already established, so this inclusion is more organic and perhaps a bit self-developing. For smaller companies, this delineation may not be so clear.

Why it Matters

This is not a theoretical exploration. In fact, in my current work, I see a project with the salesperson attempting to select a supplier and system components that should come from operations, which impacts project schedules and risks. This sales interference takes the form of emails to operation managers and engineers driving the design direction, the latter is frustrated by what seems to be an ever-changing product direction with limited time to accomplish. This extraneous input creates what I refer to as turbulent flow. There is a time for turbulent flow and a time for laminar flow. For simplicity, turbulent flow consists of conflict and indecision, and laminar flow is conflict-free with a clear direction. Conflict need not be destructive; it is how we get the best solution. Poor conflict management and ignoring the issues will likely not result in the outcomes we desire.

It can be easy to see why the salesperson acted in this way. On the opportunity side, they were the only ones talking with the customer to understand what was needed and how to achieve it. This may not have included much input from the development team or the potential project manager. Now, we are moving from a “maybe” to “let’s go,” and we may not have sufficient, traceable articulation of the commitment. From experience, the response to RFQ that does not include technical talent will have holes in it.

Opportunities for Failure

Scope Creep: How do we know what constitutes scope creep? If the development group was not included in the opportunity exploration, the translation of the agreed-upon scope, some of which is verbal or otherwise not captured in the language of requirements, may not be clearly articulated. Yet the estimates as the response to the request for a quote have accounted for the scope in cost and timing. This lack of opportunities for additional features or changes in the customer requests during the project’s execution can lead to scope creep, straining the project’s timeline and budget.

A good prevention of scope creep is:

Baselining the project’s scope.
Articulating the project’s scope.
Articulating the project scope change process to the customer at the beginning of the project.

Unrealistic Promises: Sales may commit to customers without fully understanding the project’s technical constraints, leading to delivery challenges. We are left using the estimates from the opportunity discussions without a chance to refine the scope, project cost, and delivery date. Upon moving from sales exploration to project, sales personnel may continue to follow up on these promises. This is not malicious but is often the result of less-than-perfect technical and tradeoff knowledge. I will add, from experience, the level of documentation of the agreements during the exploration of the opportunity seems less than perfect. Walking these back requires transparent discussions and a give-and-take approach.

Resource Constraints: Inadequate resources allocated to the project may limit the team’s capacity to meet ambitious customer expectations. We have seen opportunity discussions go on for six months, but when the customer decides it’s go time, the team members may be attached to other projects. The start date may not be the date the contract is signed.

Metrics, Rewards, and Conflicts: If you work, you likely have parameters upon which you are measured or rewarded. There is a saying – if you want to know why something is happening, follow the money – but in this case, we are referring to the incentive. Salespeople have incentive structures often based on project income, and yearly targets align through the sum of those projects. For example, perhaps part of the compensation package for the sales personnel is associated with project revenue or profitability generated. These structures or rewards may induce understandable behaviors from the sales personnel.

Fixed Price Contracts: In fixed-price contracts, sales may feel pressure to promise more to secure the deal without full knowledge of what is required to develop the product and deliver the project. Part of sales compensation is often based upon securing the contract and perhaps even the margins of those contracts. There is an incentive for the sales staff to intervene in the project beyond the area of sales responsibility. Fixed price contracts put the potential for the project to generate revenue and are a reason for understanding the implications of the opportunity on any would-be project.

Areas of Improvement

A harmonious interface between the sales group and project manager is essential for ensuring customer expectations align with the project’s scope. This harmony happens through the interfaces between sales and project management via the handoff from exploration to project.

Here are some ways in which the transition from opportunity to project can be eased:

Early Engagement: Encouraging involvement in the opportunity discussions to help identify what is possible and inform the development team of the scope of any potential project that may arise. This involvement can reduce the time required to move from opportunity to productive project phases. Ideally, some team portion should be included in the post-budgetary exploration of the Request for Quote. Of course, this relies on certain refinements of the quote: budgetary considerations, which encompass a range of viability; the final quote, determined after further information is acquired; and the inclusion of estimates from those who are more closely involved in the project.

Shared Spaces: We have seen the gap between opportunities and projects closed via shared online and networked spaces and processes. This comes in the form of SharePoint structures, such as a repository for these opportunity discussions to be moved into the project. The process can include refining the budgetary estimates from the sales staff through this documentation. This is especially needed if we have not included key subject matter experts in the budgetary quote and schedule estimates. Essentially including some portion of talent and time allows us to close the gap from an opportunity to a project, rather than treating exploration as separate and disconnected from operations.

Regular and Clear Communication: Establishing open communication channels ensures that both teams know about changes in customer expectations or project constraints. Communication is where a resource matrix like RACI (Responsible, Accountable, Consulted, and Informed) and communications plans can come in handy. Who is responsible for what, and in what form shall communications occur?

Scope Definition Workshops: Jointly conducting scope definition workshops aids in defining the project’s boundaries while addressing customer needs. Including sales, customer, development team, and project managers in this workshop enables a clear handoff and exploration of things known or believed in a clarifying way. We are a fan of design walkthroughs with the customer.

Negotiation and Compromise: Sales and project managers must be willing to negotiate and find common ground when customer demands seem challenging to meet within the existing scope. For example, the customer’s need may come at project pricing, making the project too expensive for the customer and perhaps excluding the project. In these cases, requirements (scope) or project costs may have to be adjusted, or the project is undertaken at less than the desired margin, which may be a strategic decision.

Documentation: Clear documentation of agreed-upon scope and customer expectations is crucial to avoid misunderstandings later in the project. This documentation will include moving from the budgetary cost and time estimate to a more refined answer to the Request For Quote.

We include some process descriptions of this in documentation, often no man’s land of the transition from opportunity to project. We recognize that for many organizations, this work is so fluid that detailed process descriptions are not possible, however, that does not mean some general description and guidance on how to navigate is without merit and would not be helpful.

RACI: For the front end of the project, it can be beneficial to create a RACI chart for the sales, project manager, and key operation figures. The RACI and the many variations thereof attempts to parse areas of responsibility and document talent to specific domain and deliverables of the project. Ideally, this RACI would be part of some description of how the company will manage the transition from opportunity to project. This is not to suggest a flow chart; for things with great variability, it is not easy to impose an idealized workflow that is ideal in mind only and not in actuality.

Educate and Align: Educate sales teams about project constraints and align sales targets with achievable project objectives. Introduce the sales team to key talent, perhaps line managers, to help with the estimations when the opportunity appears to be trending toward acceptance and opening of a project. Ideally, include the project manager in some of these opportunity discussions, especially as it appears the customer will move the company from opportunity to project.

Collaborative Decision-Making: Encourage joint decision-making involving sales, line managers, engineers, and project managers in response to quotes from scope-related choices to estimates of duration. It is in everybody’s best interest to quickly move from the opportunity to the project, but we need to do so effectively.

Risk Assessment: Conduct a thorough risk assessment to understand the implications of the transition from opportunity to project. Where are the potential pain points? For example, are there penalties for late delivery? We should know the customer’s expectations and articulate to the customer what is possible before accepting the work.

Conclusion

Moving from opportunity to project is a nontrivial task, and no single prescription exists for managing it. Promptly and effectively moving from opportunity to project benefits both the customer and the project-conducting organization, by delivering the product to the customer quickly and generating income for the supplying organization on a shorter timeline. Finding techniques that work for your specific scenario will help you move from opportunity to project successfully.