What comes first - a requirements document that will allow the project team to develop a schedule? Or does the schedule come first and the requirements are gathered during the execution phase of the project? Saving Changes...
Sort By:
George JucanManaging Partner| Organizational Perfomance Enablers NetworkWoodbridge, Ontario, Canada
The Statement of Requirements is an input to create the Project Charter (so even before a schedule is created), so there is no real dilemma. However, the requirements gathering process can be a project in itself (managed accordingly). The only area I’m aware of to join the 2 as a single project is IT/IS, where is a common practice to have Requirements Gathering as a project phase.
As an IT/IS project manager myself I often struggle with this issue – especially that some executives have the unrealistic expectation to tell them when the project will be done before we even know what we want the project to deliver. Most often I explain them that no builder will commit to a closing date until they have at least an “artist drawing”, which is equivalent to requirements for the software industry. They seem to get it, and then I offer them to use one of the following 3 strategies to resolve this:
- apply agile techniques time-boxing the iterations and doing requirements and development almost in the same time;
- apply traditional waterfall but time-box each phase to commit to a specific delivery date – whatever gets done gets done, the rest of it is “release 2”;
- apply rolling-wave, with detailed planning for requirements gathering and a high-level plan for the rest (without committed dates), with re-planning after requirements and after design phases - each of the re-planning exercises increasing the confidence level in the estimated delivery date.
Unless you know what it is you are delivering, how will you know how much effort it will take to deliver it? And as a follow-on question, how will you know WHEN you will be able to deliver it? And then lastly, How will you know you will be able to meet a schedule? So the simple answer: requirements first then schedule. Saving Changes...
Anonymous
So a System Requirements Document, containing the user, functional, non-funtional requirements are done 1st?
I thought and have seen PM methodologies perform the requirements gathering during the Execution Phase and of course the schedule is done in the Planning Phase - which is BEFORE any of the work is done (i.e. the Execution). Saving Changes...
Sounds like Agile development to me....Still... even though the steps may be compressed - you still have to understand what, when, and how long. As I remember my basic Agile development - users, developers, designers, et.al. are working closely together - the design/requirements flow out of that interaction. Still - understanding what the big picture is can only help you lead the effort. The cycle you're conducting will be delivering a discrete component of a larger whole. Understanding not only what that component is, but also where it fits in the larger picture can only help you quantify your efforts. Regards, Don Saving Changes...
Anonymous
I'm thinking now that there may be some confusion with some people in our organization when it comes to terminology.
To develop a schedule, one must know the deliverables of the project, correct? And to further define that schedule, the tasks that must occur to meet those deliverables are identified, correct? I think that people are confusing the term 'deliverable' with the term 'requirement.' When one is initially developing the schedule, does one really care what the system response is to the user inputting specific information? Saving Changes...
I understand the confusion. Deliverables are the "What" of the project. They're measured by milestones - "When". The duration of the milestones is the schedule. Requirements define deliverables, or in some cases are deliverables. And in answer to your question - if the requirement for system response requirement creates a deliverable - i.e., adding CPU to the system - then I'd say - the requirement defines the deliverable - the result of the requirement. IMO... Saving Changes...
Anonymous
Forgive some of these elementary questions as I am new.
On the initial schedule, it is my understanding that one should identify all the major deliverables and then identify the activities required to develop each deliverable. This being said, is gathering/documenting the requirements a 'deliverable' for a project?
Thanks! Saving Changes...
George JucanManaging Partner| Organizational Perfomance Enablers NetworkWoodbridge, Ontario, Canada
In most projects you will have a need and (at least high-level) requirements that will convince the management to allocate funds to get it done, thus initiating the project. I think throughout this discussion we’re dealing with a bit of confusion between the Project Management activities and the software SDLC for new systems development, usually having as major phases:
- requirements gathering
- architecture and design
- product build (coding)
- testing
- deployment
The project requirements used to write the Charter are not the same with the product requirements part of software SDLC. You can use the SDLC phases as your first decomposition level in WBS to identify all the work components that need to be done without any details (max 1-2 more levels under this one in WBS) – however, this does not allow writing a proper Project Charter as advocated by PMI.
In such cases I normally use a “slim” Charter that only states the project objective, establishes governance, assigns authority and acknowledges that project planning will be refined after each phase (rolling wave planning). The deliverables are pretty much standard (requirements document, architecture documents, working code, user manual etc) and the initial schedule/effort/resources estimates are based on previous experience with similar projects, so you can do your initial planning from the Project Management methodology.
A critical success factor is to ensure that everyone (especially executives) understands that the initial plan is a high-level baseline and planning will be a continuous exercise throughout the entire project. This includes clearly stating that no task, deliverable or milestone is cast in stone until the previous SDLC phase is completed, because each SDLC phase includes a complete initiate/plan/execute/control/close cycle.
To summarize, for new systems development there is a project management “life cycle” for the entire project with initiate/plan/execute/control/close PMLC phases; within “execute” we have the product creation with requirements/design/build/test/deploy SDLC phases, and within each SDLC phase there is another complete PMLC – basically a subproject with its own project management.
One last note, for small projects the “inner” PMLC from within each SDLC phase is treated as “project planning updates” of the overall project management, so you only have SDLC within PMLC to reduce complexity.
Saving Changes...
