I am new to this and I am researching the proper methods and project processes.
In one approach, I'm reading that in order to create the Project Plan, let alone the WBS, the project requirements must be documented. I'm assuming that the project requirements mean the user and business requirements (i.e. Requirements Specification Document).
In other reading, I see where the gathering of requirements is in the 'execution' stage of the project. If one is in the execution stage, the project plan must have already been developed... correct? If so, how can an organization proceed without the requirements?
If the requirements must be documented prior to the WBS, project plan, etc... it seems to me that a few weeks and even months (depending on the size of the project and number of requirements) before the execution phase of the project gets going.
It’s going to vary based on your organizational structure. In my current position the first hard-line document that we’ll work off of is a Project Charter/ Preliminary Scope Statement. These are combined and it give the rough outline on what the project is for, what it plans to do, lists any assumptions and constraints, the business need and a few other items. The project sponsor will sign this and we will use that when putting a plan together. Saving Changes...
George JucanManaging Partner| Organizational Perfomance Enablers NetworkWoodbridge, Ontario, Canada
The first step is a Statement of Work, which describes in plain language what the project is supposed to achieve, the business need to be addressed.
If the organization decides to address the need through a project, the next step is the Project Charter which authorizes the project. It would be ideal for the charter to be done by the Sponsor, but in reality the Project Manager is usually writing it. However, make sure that the Sponsor really understands and supports the Charter, including through formal sign-off.
The next step is the Preliminary Scope Statement, which is really a high-level planning exercise. If you look at PMI’s definition of Preliminary Scope Statement it lists almost the same elements as the Project Management Plan, but with a “10000 feet view”. Its purpose is to make sure that you properly frame the project and everyone has a common understanding of objectives, deliverables (brief description only), high-level estimates (effort, money and time), generic resources, project phases, major milestones, major constraints, major risks etc. To summarize, this is a “what” level document
The last step before starting to “work” is the Project Management Plan, which practically describes the “how” for the same elements you touched in the previous phase, adding the required details to know what will happen throughout the project. For a small project it will have chapters dedicated to scope, cost, risk, quality, resources etc. etc. etc. management. For a large project there will be subsidiary plans referenced from the main planning document.
At this point in time you have the WBS (high-level in Preliminary Scope Statement and detailed in Project Management Plan) so you can start the project execution.
The discussion above was from Project Management Life-Cycle. Now, switching to a
Systems Development Life-Cycle perspective, that’s where you have Business Requirements, Architecture and Design, Development, Testing and Roll-Out (to keep it generic). There are many people that do not make a clear distinction between PMLC and SDLC, so make sure you wear the right hat to see the angle that you need.
