I am completing an RFP. The document requests that we submit 2 project plans "in line with PMI Standards." Can someone point me in a direction where I could find/identify these standards, to ensure that my project plan meets the PMI guidelines? Many thanks in advance for any insight/assistance. Saving Changes...
I do not have any plans to share; however the PMBOK(R) Guide explains exactly what goes into a plan. You should be able to look at your current plans and see if they fit. If not, adjust accordingly.
Elden F. Jones II, PMP, CMII Sr. Project Management Engineer ComGlobal Systems, Inc. Saving Changes...
Mike Cooper PMPPrincipal Project Manager (retired, sort of)| New England Project ServicesWestford, Ma, United States
I had developed a project plan template that followed the PMI guidelines. It is freely available from my website, www.westfordconsulting.com. You could use this as a checklist for your plan. Saving Changes...
A project plan is a means to an end, not an end in itself. It should guide all the members of the project in executing the plan and the team should have mental ownership of its contents.
I am fully in favour of all the checks and balances of the PMBOK, but you must use some practical understanding in applying them.
The important issues are communication and risk management. If you read the PMBOK and are overwhelmed, get advice.
Most importantly, scale the provisions of the PMBOK for your project and your capability - I would venture to say that few projects are capable of running with all the provisions of the PMBOK working, and this is not because there is anything wrong with the PMBOK, it is because people have to learn how to use them.
So, be careful that you do not miss the important issues, but be careful also that you do not produce a plan that people will not understand and cannot perform by adding too many management controls. Saving Changes...
Anonymous
Thank you all for your ideas and insight.
One more question: When the RFP requests a Project Plan do you perceive that they are requesting a workplan in Microsoft Project -or- a charter/project plan document written as a Word doc.?
When you are responding to an RFP, try to avoid the following pitfalls, by implementing contractual controls and using a PM that knows how to use them:
1. Contractual clauses override your Project Charter: Make the management processes in your project plan part of the contract by annexing them to the ?Business Contract? and make sure they supersede any other contractual clauses that the contract may have; 2. Acceptance Confusion: All development projects have phases ? understand them! Typically, the objective of a phase is to clarify what must be done in the next phase. Avoid quoting fixed prices across multiple phases ? don?t even consider quoting using tolerances that sound ?sensible? unless you are ABSOLUTELY sure that these tolerances are applicable to you?re your team capability; 3. (2) is best achieved by describing an acceptance process in your project plan and then applying that process to all contractual deliverables; 4. Non-technical Clients signing acceptance on technical deliverables: Try to avoid the situation where your client is expected to sign off a technical document as accepted. You may get them to do so, but later on when the signed off document turns into something the client does not want, you have a mess on your hands ? there is no easy way to do this without asking a client to use a competent technical person to review your deliverables (make this part of the contract); 5. Verbal scope creep: Make sure you control the inputs to the phase and that you do implement controls that force scope changes by a documented means ? If it is not written, it is not said. This will control risk for both parties. By the way, this is the hardest thing to do, since people want to please clients (especially the marketing types and developers), and sometimes try to ease communications by accepting informal changes ? The bottom line is you want to get paid when you have done the ?job? and this must be clearly defined; 6. Missed signoffs: All phases have outputs. Make doubly sure that these outputs are signed off by the client (see 4). If you miss signoff, you build a case for non-acceptance from the start. It is ALWAYS more expensive to correct deliverables than to delay the commencement of a next phase; 7. (6) is best addressed by having a clause in the contract that puts the onus of acceptance on the client and a time/cost budget for signoff of a phase. You may want to charge a standby fee for delays in this area; 8. Who defines acceptance? All acceptances have conditions ? Who defines these conditions and who defines the acceptance criteria? Make sure you have the answers to these questions locked up in the contract and if it is you, them make sure you allow for time and materials in your budget to do so; 9. Operational Liabilities: All deliverables operate in an environment ? Make sure you specify who pays for the operational environment, especially when it comes to third party tools and equipment. Also make very sure your client understands the costs and budgets for these costs separately ? this MUST be in the contract, and NOT in the Project Charter (oh and I hope you are sure that these tools will work reliably is you specify their use!); 10. Software unknowns: If you are building software, you are exposed to two issues: a. There is no ?objective? (read mathematical) way to estimate the resource and time required to build software, given requirements ? this statement comes from ?Complexity Theory? ? take a look at my discussion in the process improvement under ?Objective Estimation in Software development - Can it be done or is it a pipe dream? b. Even when the functional requirements are met, the non-functional requirements can break you ? take operation under load as an example: Do you know how many users you will have, do you know what concurrency you will have and most importantly are you able to test and prove that your software performs within spec under these conditions? Load testing software is not expensive for nothing, make sure you budget for this kind of expense! 11. Warrantee: Be careful of ?warrantee? clauses. You could be signing a blank cheque if you are lax in defining this criteria!
CYA: Most of all make sure you know when to walk away from an RFP. If your client does not agree to reasonable risk controls then you may not want to do business with them. A big part of this is controlling your marketing and sales people ? they can sink your company in order to make sales targets so let them know how you work before they sell your services.
