In many large technology projects, internal or external pressures prompt management teams to select services or commercial off-the-shelf (COTS) technology too early. “Let's spend the money while we have it” and “Our competition is using it” are dangerous ways to begin the sourcing process.
Moving too quickly into project execution will increase the probability of project failure and lead to cost overruns, scope creep and rework. Preparing for procurement and solicitation are planning processes, while the actual solicitation, source selection and contract administration are executing processes. In practice, these distinctions can be blurred. Recognizing the integrative nature of planning and executing processes is critical. How many requests for proposals (RFPs) have you seen that have a detailed work breakdown structure (WBS) that defines the scope of work for the respondent?
Some companies rely on consultants to prepare RFPs, but, unfortunately, consultants fail to instruct their clients to produce the proper planning documents. Some planning outputs, such as WBS, project assumptions, risk events, project charter and scope statements, are critical inputs to procurement and solicitation planning. If these planning documents are not in place or do not have the proper quality and clarity, the project manager must slow things down to educate the stakeholders.
Because stakeholders often do not have a strong background in project management, they may become confused as to the phase or status of the project. To limit confusion, the project manager must gauge expectations, taking the time to discuss the project plan at a high level with all stakeholders to ensure a common understanding of the project methodology, the big picture, the project steps and current status.
Don't confuse education with communication. Lengthy e-mails with project plan documents attached are not a substitute for understanding. Education implies a level of teaching, coaching and/or mentoring. One-on-one sessions or small groups in an informal setting often work best.
Scope Statements
If the project, particularly one that requires software development, does not have clear scope statements, you're in trouble. Scope statements for projects that require a COTS software package and some software development across a corporate enterprise should define:
- The functions of the department or business area, including five to 10 concise sentences of what the department does and how it will be impacted by the project
- The scope of the COTS software package to be implemented in the department or business area, including 10 to 15 concise sentences on how the COTS software will be used and key functionality to be utilized as it relates to these functions.
- The tangible and intangible benefits to the department or business area, including three to five concise sentences stating the tangible benefits that will be expected to result. In some instances the benefits may be quantifiable, and in other cases, they may be “soft.”
- The business and technical issues associated with the implementation, including a list of critical issues that cannot be resolved in this phase of the project but must be addressed in the requirements and design phase.
The project manager must have the project team develop strong, clear scope statements for the project before any discussion with vendors begins. A good scope of work will give vendors a strong sense of what the customer wants and will reduce the chance for inflated bids.
Figure 1. This diagram illustrates a simple way to trace requirements to the business process.
Large, cumbersome RFPs may be helpful in evaluating vendors' capability and pricing, but they often detract from the core planning processes. These mammoth RFPs often tend to focus on what the customers want, as opposed to what the customer needs. Needs align with the business objectives, while wants often do not.
The Search Starts
Once RFP solicitation begins, vendor briefing, conferring with numerous vendors, proposal reviews, question-and-answer time and live test demonstrations can be exhausting for team members. Vendors may steer requirements toward their solutions and technology to gain the business. Since COTS products were not developed for any one particular customer, they must be modified or integrated into the customer's environment. If these interfaces have not been identified, the customer may end up with the wrong product or technology in the worst case. In the best case, the project manager will have underestimated the amount of work to be performed. The WBS must include all the work to be done by the project, including integration tasks.
Have the vendors respond to a general business problem with business objectives that support the organization's strategic objectives. Vendors can be allowed to bid in a nonbinding contract format with budget estimates that will assist in cost estimation. These documents often are known as requests for information (RFIs), which also can help identify development or integration tasks.
RFIs educate team members while allowing more time for a customer/vendor relationship to develop, as well as an opportunity to access vendor capabilities, their subject matter expertise and their project management capabilities.
Do not rely on the vendor to provide a project schedule or planning. The vendor deliverable usually is just a piece, sometimes a much smaller piece, of the overall project. Vendors offering COTS products will not align the project objectives with business objectives. They are not capable of performing scope planning, definition or verification nor can they do your communication planning or risk management. Seldom can they independently identify your requirements if they also are supplying the COTS package.
Understanding the Business Case
To facilitate a requirement definition, the project manager must have certain technical knowledge of the project and a thorough understanding of the business case and business process.
Developing detailed functional requirements often is neglected. Functional requirements should always support the business process. Business may be changing as a result of process improvements, regulatory amendments and technology advances, and requirements must anticipate the changes.
Developing a high-level, one-page process flow of the business area that is targeted is a good approach. It should be understandable, but not simple or obvious, otherwise the stakeholders will think the project manager does not understand their business. It should reflect all the major business areas impacted by the project, thus verifying the scope statements. This document can be enormously helpful in keeping all the players on the same page, creating a common understanding of the project scope as it relates to the business processes impacted and setting the stage for more detailed functional requirements.
More detailed process maps can be done if needed. To generate good requirements, project managers must understand the individual process steps, what users need, when they need it and why. Here, functional or process requirement definition takes on a new meaning. It's no longer a mish-mash of features of functionality, but specific functionalities that can be traced to specific business processes. At this level, selection of a vendor or product becomes much easier. Moreover, vendors appreciate customers who know what they want, especially if the vendor can provide the solution.
Each process step is determined to have package applicability. In other words, is the COTS package being used in this process step? If so, what should the package do to facilitate the process? The more detailed the functional requirements, the better likelihood of satisfying stakeholders. To eliminate duplication of requirements, a simple database can enumerate the requirements and trace them to the business process.
Contract Negotiations
Firm fix price (FFP) contracts best manage risk for the purchaser; however, they require a more in-depth knowledge of the project. A centralized contract office may not be equipped to provide the expertise on negotiating large professional service contracts or contracts that include the development of a product.
Payment milestones, holdback monies, acceptance criteria and change control are critical parts of an FFP contract. To ensure these conditions are met, a project manager may be more involved in the contract negotiation process. Certain milestones in the contract or statements of work must be reflected in the project plan. Once again, the integrative nature of project management comes into play.
When the remaining planning processes are complete, it is up to the project manager to decide how to proceed through vendor selection. Now may be the time to issue a formal RFP, conduct a live-test demonstration, visit vendor sites, etc. Make sure adequate time is given for contract negotiations.
Last, once a contract is executed with a vendor who is providing a key technology or service to your project, the bulk of project management planning processes must be completed, not just beginning. Activity definition, duration estimates, cost estimates and budgeting, and a completion project plan must be developed in harmony with the vendor contract, requirements and deliverables. Include the same project documentation regarding scope, objectives and requirements in the vendor's statement of work to ensure linkage and traceability.
Once source selection is complete, this integrative nature of project management continues. A formal relationship with a vendor will require more in-depth planning processes, revisiting risks and additional resource planning while executing, including scope verification, quality assurance and team development. PM
Jack P. Ferraro, PMP, is president of Ferraro IT Management Services Inc., a consulting company that specializes in information technology project management with extensive experience with process automation technologies.
