Posted on

Project Procurement

Agile Project Procurement (Comparing Apples to Oranges)

In PowerPoint presentations, every project procurement solution works and every business case rocks but that’s not the case in real life. Bad project procurement planning and choosing the wrong solution are key risks in a project. This has been one of the most time and energy-consuming activities for me, especially in situations with more than 3 companies on services not easily comparable. Project Methodology Main Page

IT Project Procurement

In my field, which is IT, the most complex procurement processes are related to software solutions (hardware related processes are more standardized). Comparing software from different providers, although for the same requirements, is often like comparing apples to oranges. Price is not always an indication of quality. I have seen both scenarios; paying premium dollars and getting bad quality from big names like HP, Oracle and IBM. I have also seen companies bidding with low prices to get the deal, then not being able to fulfill their promise. Big companies can afford good marketing and selling teams, the key skill is driving the perception of quality by building excellence with their polished presentations.

How do you protect the project from price speculation and the marketing window dressing? This is a technique that delivered good results for me on several occasions, making the project procurement process of choosing between apples and oranges less painful. There are 2 prerequisites to this approach. First, you should not be in a hurry. It is good practice to start as early as possible with the planning of the procurement phase. Second, you must have some negotiation leverage with the vendor companies.

Project Procurement Steps

I call this approach the agile project procurement, and it goes like this:

1) The team agrees on the quality criteria and price/quality ratios for selecting the winner. The selection criteria is approved by the steering committee in order to have it written in stone.

2) It is key to start the process fast by sharing a short version of the requirements/procurement-SOW in an RFI with the problem you want to solve and the objectives. Having the list of prospective vendor companies predefined saves time. The companies are asked to propose their solutions based on their past experiences for similar requirements. It is very important to keep this first cycle short in order to use the time later. In this phase, you also request a high level cost estimation.

3) Based on the feedback of the companies, you use the selection criteria and choose 3 companies.

4) All the companies are notified to enter the second round and are asked to build a PoC (proof of concept) or prototype of the proposed solution in 2-4 weeks. Usually companies agree to build the PoC when the process is important to them. If one of the companies does not agree to build the PoC, this might be an indication of trouble and needs to be investigated. Either the company is not very interested in the process, resulting in a low level of commitment, or worse they’re not capable of delivering the required software.

5) After the PoC is delivered, project stakeholders and business users are invited to have a dry run of the software. After their testing, they must provide formal feedback.

6) Based on the gained experience and user feedback, the original RFI is enriched to a RFP and the companies are asked to provide the final pricing.

7) The final selection is done using the original approved selection criteria, which includes the feedback of the users.

Project Procurement Pros and Cons

This project procurement approach is no silver bullet, it has benefits and drawbacks. On the benefits side, it deviates from the classical waterfall planning of procurement by bringing stakeholders’ and users’ feedback into the equation. It reduces risk by braking the power-point tradition and asking the companies to prove their capability to deliver. And it increases the competition, resulting in better price/value positions. This also helps the companies get a better picture of what they are committing too. The benefits are lower risk and better quality.

Some of the drawbacks are that requires more resources compared to the classic procurement phase. The procurement process may cost more and you may lose some of the companies who do not want to invest significant effort during the selection phase.

Posted on

Project Change Management

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

The point of the project change management process is not to prevent changes. It is to ensure that changes to the baseline project plan are carefully analyzed and are necessary to produce the approved project scope and deliverables.  Change order requests are a central element in the project’s change management process. All changes to the project baselines for scope, budget, schedule, quality and risk are documented and analyzed as part of the project change management process. It’s the project manager’s job to gather the information about each change request and analyze the effect of the change on the entire project. This information, along with the project manager’s recommendation, goes to the project sponsor, the change control board or the configuration management committee for final approval or disapproval of the request. Change Control Main Page

The project manager’s responsibility in the project change management process is important from several perspectives. First, you need to ensure your stakeholders and team members submit change order requests and go through the change management process. You should never allow stakeholders to make changes to team members’ assignments, the specifications of deliverables, or to add new deliverables or tasks without going through the change management process. By adhering to this requirement, you prevent scope creep. That’s where the project plan changes without explicit analysis, approval and control.

Second, your job is not to prevent changes to the project. You should encourage people to come up with new ideas and better ways of doing things because that improves the project. By encouraging change requests, you maintain good relationships with the project stakeholders.

Third, a consistent project change management process built around change order requests ensures that all ideas are treated the same. Requiring change order requests whenever someone wants to alter the scope, duration, or budget is a best practice. It allows you and the sponsor to consider the consequences of that change on the rest of the project. Without change order requests, seemingly inconsequential changes to the scope can cause substantial increases in the duration and/or the budget that no one anticipated.

Fourth, a little bit of thought about consequences, especially unintended consequences, is worth the time invested in the analysis. Many people can request a change to a project but you, the project manager, should always assess the impact of that change on the project’s scope, duration, cost, risk, quality, and resources. You should also include your recommendation on whether the sponsor should accept or reject the change order request.

Project Change Management Process

Project Change ManagementIt’s very easy to go too far with paperwork in the project change management process. The point is not to make change control a bureaucratic jungle of forms and procedures. You want to make it easy and straightforward so you can promptly process change order requests and give decision-makers the data they need. As importantly, the change management process should not aim at reducing everything to a single piece of paper. It’s wise for you, or others engaged in evaluating change order requests, to actually talk with the people who submitted it. Stakeholder management is most effective when people feel that you are listening to their ideas or the problems they have identified.

Below is a bare bones change order request with the key elements you and sponsor need. A stakeholder does not have to fill out this form. An effective processes is for you to use it as a guide in your discussion with the stakeholder about a change.

Project Change Management: Minimum Change Order Request Elements 

The dates of each step and the identity of the people should be included in the change control process.

  1. DESCRIPTION of the change. The focus should be on the specifics of how a change order request will alter a deliverable’s specification or the process used to produce it.
  2. REASON the project plan should change. Include specifications of the problems this change order request will solve.
  3. SCOPE- Impact of the change order request on the project scope. The project plan is a pyramid of deliverables with the scope at the top. The deliverables throughout this pyramid support the higher-level deliverables above them. You need to analyze changes to lower-level deliverables in relation to the impact the changes will have on the higher-level deliverables.
  4. RESOURCES & WORK – You need to assess, and usually re-estimate, the work required in the tasks affected by the change order request. That should include a description of changes required in the skill sets of the people working on the tasks affected by the change.
  5. COST – You should estimate the cost impact of the change request in terms of materials, equipment and supplies as well as changes to existing contracts and the cost of the people assigned to the task.
  6. DURATION & SCHEDULE – You should use project software to model the impact the change order request will have on the duration of the affected tasks. The software will determine if the change will affect tasks on the critical path and how the change will ripple through the project and affect the overall completion date.
  7. RISK – You should review the list of identified risks and determine if the change request affects any of the existing risks or creates new risks.
  8. QUALITY – You should assess whether the change order request will affect the quality or specifications of any of the project deliverables.

It is a useful stakeholder management tactic to include the person making the change request in the analysis. At the very least, you should review the analysis with them before passing it on to the project sponsor. It’s best if the requester can agree with your analysis. But it’s also important that you know where you disagree before passing the change request on to the decision-maker(s).

Project Change Management Process Steps

Step 1: As the project manager, you receive a change order request. The first step is always to see if the situation can be resolved with corrective action that would not change the project plan or any of its components.

Step 2: If corrective action fails or is not an option, you analyze the change order request. You document each of the items listed above and make your recommendation for approval or rejection of the request. You should complete the analysis in a timely manner and include quantification of the impact of the change on the project scope, budget, duration, etc. as detailed above.

Step 3: You forward your analysis of the change order request to the project sponsor with your recommendation for approval or rejection of the request.

Step 4: The sponsor decides whether to approve or reject the change order request and the consequences. You document the result.

Step 5: If the sponsor approves the change request, you implement it by changing the project budget, schedule and scope as necessary. Then you alter the team member assignments to reflect the changes. You follow these same steps for all change order requests.

Step 6: You should archive the change order request and all supporting documentation. This information is invaluable for handling future requests.

Learn about Project Tracking & Status Reports

You can learn all these skills in our project management courses. Take a look at a course in your specialty.

[button link=”http://162.144.114.198/~jwkdwgmy/it-project-basics-111/” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/project-management-basics/” size=”medium” style=”info” color=”#1e14a8″ border=”#940940″ window=”yes”]Business[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/construction-project-basics-121/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Construction[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/healthcare-project-basics-131-2/” style=”info” color=”#1e14a8″ window=”yes” bg_color=”00000000″]Healthcare[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/client-project-management/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Client Projects[/button]