Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Information Technology, Outsourcing, Procurement Management
Where does the Vendor RFP/Evaluation/Selection process for a software implementation project take place in the PM phases?
I'm a new project manager barely learning...I have been assigned
on a project where I'll be aquiring a new Digital Asset Management (DAM) system. My question is, at what point do I do the vendor evaluation, selection process, sign a contract, etc.? My thought is it would be during the Execution process, because I would first have a Procurement Management Plan where I would outline how we will search for and evaluate software vendors. However, this project IS about implementing that vendor's sfotware, so during my Planning Phase, I would know what my final software selection was so that I can develop my WBS, accordingly.

So that's why I'm confused. Would I then do my charter and ensure I already know who my software provider is and include it in there, then move on to planning where I can outline my WBS specific to that vendor? So that would mean my vendor selection occurs during the Initiating process? Or do I do this as part of the Executing phase and then go back to the Planning Process to build my WBS further--wouldn't that mean my timeline could also change now that I know my vendor requirements specifically to build that WBS?
Sort By:
Marlene your initial thoughts are correct. The vendor selection process is part of the project execution and you will have tasks and activities in your schedule reflecting this. But you need to move away from the idea that everything will be cast in stone when the project starts. Based on the outcome of the selection process you might have to rebaseline your schedule because not all vendors follow the same process and timeline for implementation. So rebaselining is a given. Obviously you have stakeholder expectations to meet wrt timelines and these expectations would be input into the selection process i.e. if a vendor is unable to deliver within the expected timeframe they will score lower.

There is obviously an alternative approach where the RFP and selection process is considered a separate project in a bigger program i.e. you would initiate a project for the selection and once that is done kick off the implementation project. This approach has the benefit of keeping the focus where it should be but the danger of losing sight of the bigger picture. So you need to keep an eye on the 'master' plan to make sure you are aware of any knock-ons from your selection project.

Personally I prefer the first option.
Executing Process "Group" PMBOK Table 1-4 p. 25.
Marlene, having participated in several vendor selection and implementation projects, these are often 2 separate projects.

Depending on what vendor is selected, implementation will look differently, sometimes vendors bring with them a implementation methodology.

Also selection and implementation have a different set of key stakeholders, implementation involves heavily change management efforts (which sometimes also are a separate project).

PMI phases are NOT initiation, planning, execution etc. These are process groups that contain processes to manage the project, not to do any product oriented tasks like selecting a vendor or implementing a solution. They iterate, so execution processes will be carried out all along the project (like acquiring resources, team building).

Vendor selection also might have phases, specific to vendor selection, sometimes organizations have standards around this owned by procurement people. A typical phased lifecycle would be gather goals/requirements, define selection criteria, create vendor list, do RfIs, build a SOW, maybe buy market research, issue RfP, check incoming proposals, invite shortlisted vendors, select, negotiate contract, initiate implementation and change management.

For the difference between phases and process groups see:
https://www.linkedin.com/pulse/pmis-pmbok-...nta-pmi-fellow/
Generally speaking, Executing processes include these.
Marlene -

this is where you need to balance PMBOK theory with real world context.

If the vendor has been pre-selected, then you might certainly work through some high level scope, schedule & cost planning as part of initiating activities, but at some point depending on how much detail is desired and the nature of the contract you may end up getting to much greater detail during planning with the contract signoff potentially being one of the exit criteria from planning to execution.

With that approach, the procurement activities would focus on monitoring & controlling during the execution phase of your project.

Kiron
Thank you all, I appreciate everyone's help!
Trying to expand what @Kiron well stated in this short space. And talking about what I am facing from long time ago. The topic here is "solution". Taking about the real world that is not so real in some places there are two roles involved: business analyst and project manager. Before the project exists, the business analyst start working before the initiative exists understanding the business problem and creating the solution at high level, what does mean with the deeper understanding that the time allow. All this is making before a project exists and will be document inside the business case which is the document to get the agreement to start the initiative. Remember that solution is equal to "the thing" to be created plus "the process" (project) to create it. So, inside the business case, things that are closer related to project will be included like the approach to take into the solution (buy or build). The business case is approved then the project start. From solution requirments, mainly product requirements, the project requirements are defined. Between then, if inside the business case the decision of "buy" was taken then is time to define all needed to project procurement. The timming for project procurement you can see that inside the PMBOK. In my case I follow the process as stated and worked for me. Take into account that the role that defined the solution (business analyst) must be closelly involved in the process becuause the business analyst owns the product requirements.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."

- Douglas Adams

ADVERTISEMENT

Sponsors