Managing Expectations in Large-Scale Enterprise Projects — Part 2
In my last post, I explored a foundational understanding of expectations in projects. I touched upon the importance of expectation management and the four factors that influence it.
With a typical large-scale project lifecycle featuring six stages, it’s helpful to see how we can optimize each for successful expectation management. This article will dig into the first, and often most frustrating, stage: collecting stakeholder requirements.
RFPs and other stakeholder briefs
Few documents induce as much frustration as Request for Quotations (RFQs), Request for Proposals (RFPs), and similar documents. These are essentially all stakeholder briefs — a set of requirements for a desired solution.
Though often used interchangeably, RFIs, RFQs and RFPs are subtly distinct.
- RFI (Request for Information)
Typically, a prelude to the other documents. Asking for a simple overview of the vendor, its approach, relevant experience, and similar high-level information. As an NDA is not required for this level of information exchange, it is used to shortlist relevant vendors before providing the potentially sensitive project details. - RFQ (Request for Quotation)
Primarily price-focused, RFQs ask vendors to quote the cost for a specified list of requirements. Often, the requirements are augmented with legal clauses and compliance requirements and will expect a fixed-price-fixed-deliverable offer. RFQs are typically used for off-the-shelf products, solutions that require little customisation and often have a fixed price already associated with them. - RFP (Request for Proposal)
More holistic, RFPs request proposed solutions to a problem, typically covering price, approach, and timelines. RFPs are typically used for more unique situations requiring a custom solution contextualised to the organisation’s specific needs. The initial request typically defaults to fixed price, but given the complexities of such problems and many unknowns, there may be room for negotiation on the pricing model. This article will focus on RFPs, as those have the highest number of requirements and often have difficulty managing expectations.
The challenge with RFPs
In my experience, organisations with a strong understanding of the problem will either solve it themselves or go into significant detail on what the solution should look like. This will be apparent from the RFP, which will include specific steps, designs, and more. In this case, the organisation is simply looking to hire resources to execute its plan.
However, some RFPs cause a lot of frustration. The frustration stems from them being created by an organisation with little knowledge of how to achieve that solution or sometimes even what the desired outcome should be.
Here are seven reasons why traditional RFP processes can set up projects for failure:
Lack of coherence
The problem is assigned to an owner who will attempt to curate a list of needs based on diverse input from teams with often competing interests. Sales may push for advanced analytics, while Operations might insist on back-office efficiencies. These disconnected requests are then stitched together, lacking coherence or alignment.
Vague stakeholder requirements
Stakeholders with limited technical understanding will compile a wish list of incomplete capabilities. For example, requesting “an intuitive user interface” without specifying the key features that would make it intuitive. The vagueness confounds vendors who are left to guess what’s actually needed, especially as intuitiveness differs between countries and even organizations.
No fact-checking from stakeholders
It is not uncommon for RFPs to demand a particular architecture or software solution to be used because the problem owner has heard good things about it. However, they usually do not have the technical expertise to see if that is the right solution to their particular problem.
Misguided problem research
The RFP writer might research related problems online to see how other organisations have approached it. For example, strategies for cloud adoption or management. However, the vast majority of these are intended for small businesses and are not suitable for large enterprises, certainly not regulated ones.
Large enterprises that have gone through this process tend to be a bit more cagey about publicly sharing their methods and outcomes as, typically, a major project will have cost them considerable time and money.
Lack of flexibility
Traditional RFP processes, often rigid and linear, struggle to accommodate the dynamic nature of modern agile contracts. It is common for RFP owners to grasp the concept of a technology just enough to drive the proposed solution in a particular direction without fully understanding its relevance or providing the essential details on how to deliver it.
Compliance without context
Adding fuel to the fire, departments such as legal might insert a slew of compliance requirements, while security teams often add layers of encryption and data protection rules. While these are necessary, their inclusion often lacks context.
Fixed price waterfall
While IT and application development teams increasingly adopt Agile methodologies, procurement, legal, and finance departments still often operate in a more traditional, waterfall manner. They expect a proposal to outline every deliverable and timeline in excruciating detail. This conflict can severely limit an organisation’s ability to engage in more flexible, agile contracts.
Improving expectations management
For newly assigned problem owners tasked with creating an RFP, there are some steps to consider that can help produce a better class of RFP and manage the expectations of all involved parties.
Avoid technical specifications without expertise
If your team lacks an experienced technical architect, it’s prudent to refrain from including technical specifications. Uninformed technical specifications are more likely to cloud the waters and force the solution down the wrong path. By all means, discuss the topic with the shortlisted vendors, but avoid making it a hard requirement until it is well understood.
Focus on business outcomes
Rather than dwelling on solutions and technical specifics, centre the RFP on specific, quantifiable goals and desired business outcomes.
Phrases like “the system must be able to process 1000 requests per second” provide far more helpful guidance to a vendor than ambiguous terms such as “the system must be fast” or attempts at misinformed technical specifications such as “the system should use a faster Oracle database”. The SMART goals framework (Specific, Measurable, Achievable, Relevant, Time-bound) can help define more helpful objectives in the RFP.
Align and prioritise the different needs
Engage each department with an opinion on the problem and input for the solution. Ensure goals align with overarching business strategies and each other. Where required, include multiple departments in a single discussion to achieve this alignment.
Using the flow of data or requests as a basis can be helpful. As each request flows through the area each department is interested in, the department’s needs are applied. This should flow smoothly from when the request is created to when it is completed. You can use a similar approach to establish priorities. Which steps are crucial to closing the request (high priority), and which are nice-to-have (low priority)?
Consider a discovery period
It is immensely valuable to incorporate a discovery phase before fully designing and executing the solution. To meet procurement requirements, it might be necessary to go through this with more than one vendor, increasing the cost but likely also uncovering many more insights and ideas. This will also create an opportunity to work with the vendors, trialing the experience and leading to a more confident selection. If a separate discovery phase is not possible, it may be worth negotiating a free pre-RFP assessment with multiple vendors, a full-day workshop, for example. This will at least provide the vendors with slightly more insight than a vague RFP.
Involve experienced technical personnel
For better outcomes in technical projects, engage a technical individual with relevant experience to help scope the project. This individual should remain responsible for overseeing the vendor delivering the scope throughout the project, ensuring accountability. If such a person is unavailable within the organisation, consider an independent contractor. Using a freelancer can reduce the risk of a conflict of interest as it separates design from development.
Involve the actual users
Too many RFPs and briefs are created by managers doing what they think is best for their team when usually they are not the ones that will be using the solution. Let the actual users have a voice. They may have had prior experience with solutions that worked really well or ones that did not work well, so they can be avoided.
Modernise less agile departments
Engage C-suite executives early on to gain their support for a more agile approach. Organise training and workshops to educate non-technical departments about the benefits and mechanics of Agile methodologies. Ensure their needs are met, but work with them to contextualise those needs and make them specific to the problem and desired solution.
Final Thoughts
The traditional approach to creating RFPs in large enterprises is fraught with challenges that stem from a lack of technical expertise, misaligned stakeholder interests, and an outdated, rigid procurement process. This often results in vague, inconsistent, and overly complex RFPs that fail to communicate the organisation’s true needs effectively, leading to suboptimal outcomes.
A paradigm shift is needed in how RFPs are crafted and managed to address these challenges. This involves a move away from briefing technical specifics without having the right expertise, focusing instead on clear, quantifiable business outcomes.
Aligning and prioritising departmental needs, incorporating discovery phases, involving experienced technical personnel and actual users in the RFP process, and modernising less agile departments are crucial to creating more effective and relevant RFPs.
With a stronger RFP foundation in place, the next step is to optimize the requirements gathering phase. This is what we’ll explore in the next article as we discuss how clear priorities and risk awareness set the stage for successful delivery.
Who is Thomas?
Thomas is a highly accomplished digital transformation leader and Fractional CTO at MISSION+. With 21+ years of experience across FinTech, telco, logistics, and cloud transformation, he excels at bridging C-level strategy with actionable execution. As a prolific author, Thomas has written multiple blogs and whitepapers in which he shares his ideas around technology, project management, and problem-solving. Feel free to discuss your large-scale project delivery headaches with Thomas by reaching out at hello@mission.plus.
