The document provides an overview of key project management terms and principles including the project management body of knowledge (PMBOK), the triple constraint of time, cost and scope, requirements definition, project planning, work breakdown structure, scheduling, earned value management, risk management, and some project management proverbs. It emphasizes the importance of scope management, configuration control, risk mitigation, and using tools like the work breakdown structure, scheduling, and earned value management to manage a project successfully.
4. PMBOK Project Mgt Processes From PMBOK , Fourth Edition, 2008 Time F O C U S A R E A S
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
Notas del editor
Founded in 1969 and has experienced phenomenal growth through the 1990’s and into this decade. Credited as an outgrowth of WW2 projects. D-Day invasion Lend lease program and convoy logistics Southern Pacific campaigns Manhattan project and atomic weapons uranium and plutonium PMP has rapidly become a worldwide recognized certification promoted by many corporations and often a key to advancement. Close to 260,000 PMP’s world wide PMBOK is the key to the kingdom and the major PMI success
Initiating 2 Planning 21 Executing 7 Controlling 12 Closing 2 Should come as no surprise that planning is the highest quantity group – analogy of paint job. Short cuts i.e. avoid them if possible. Knowing you are avoiding processes and steps is usually the up front planning Not even knowing you should do something is usually in closing
You may be juggling numerous projects within your job, or you might be dedicated to a specific project. The key word here is temporary. Programs are most often defined as a collection of projects. Projects can stand alone, or be a means to a definable program deliverable.
The Triple Constraint is an often cited concept in projects. A NASA term, better - faster - cheaper is often replied with the quip, “Pick two of them.”
Are your stakeholders the funding unit, the “holder of the budget.” Are the customers likely to want or have a definite need for the deliverable. Or, is the deliverable at the whim of the stakeholder and the customer possibly hostile. Has this project just literally taken of the drawing board and rushed into reality? Or perhaps, has it been “knocked around” for a while now? If you are the PM or a member of the tea, is it a good fit for you? Or are you a reluctant participant? If so, then do something about it.
PLEASE spend time on these questions and answer them to the best of your knowledge. Can this project be done within the cost constraints of the budget? Or is there empirical evidence that it is cost constrained or mission impossible. Be prepared with flow charts and diagrams as they are always a better representation of functional deliverable and requirements than words. Is there adequate functional requirements? Is the actual Statement of Work readable and a value added document.
PLEASE have customers and stakeholders sign off on requirements documents. Be prepared in advance to correct misinterpretations and erroneous assumptions from yourself, the team, stakeholders, and customers. Once there is agreement all around then document it and monitor and manage the changes. Visual aids ARE A MUST! Articulate and educate the PM staff and others on specifying and potentially changing requirements documents. Remember configuration management.
The earlier you are part of or the PM on a project, the more this process will aid in the life cycle of the project. Constraints – there are always constraints – internal or external. Interrelated projects – none, some, or many. Does IFMP come to mind? Please know the customers and the stake holders and identify pitfalls. What is the deliverable? Know it inside and out. Know when you are finished and what the approach is to that. External limitations, possibly legal, or possibly they are actually restraints and not constraints. What is your legal position if any regarding staff, policies, approaches, etc.
Do not fall into the trap of “I don’t need no stinking project plan.” Or perhaps you think your project is too small. Ha-Ha You will define yourself, the stakeholders, customers, and what you expect of your staff. Every project has a “hand off” to something, somebody, or some process that will own it (O&M). Know what this and plan for it. The project plan is the “tie-in” to all other documents.
The bigger the project and more complex, the more a WBS becomes a necessity. The WBS is the basic building block for a project. A functional staffing chart IS NOT A WBS. Absolutely necessary for a cost estimate, time sequenced schedule, and Earned Value Management.