I'm at a new company that utilizes a pretty healthy envisioning phase, so that at the end of this process the charter is signed-off on and the project officially starts. So by the time this has happened, there exists a detaled business review (key business rules, workflows), technical reviews (assessments, architecture review, prototyping), as well as the use case/software requirement specs. So by the time I am to hold the WBS meeting with the team there is tons of information to deal with.
My question is, what would be the best way to approach the team for the WBS meeting knowing that there is enough info for me to put a framework around what the deliverables are? Would this be too presumptive? My experience has been using brainstorming sessions to do top-down WBS work, but brainstorming has already (for the most part) been done. Any help/guidance is appreciated!!! Saving Changes...
Sort By:
Mark KromerTechnical Product Manager| Oracle CorpOviedo, Fl, United States
If you are entering the project after the kick-off and discovery phases AND their is till no high-level of objectives and deliverables, then you'll have no choice but to go back to the stakeholders, hold meetings and at a minimum, validate those deliverables to build a high-level draft WBS.
If those are already documented, you could try to build the WBS from those notes and perhaps 1:1 conversations, and then follow-up with a validation session where you send out the draft WBS ahead of time for review and then walk-thru your WBS draft with the stakeholders.
That latter method would be a meeting to gain approval as opposed to bottom-up brainstorming ... Saving Changes...
Thanks I was suspecting the pre-draft/review would be a good way to go. Saving Changes...
Peter WrightProgramme Manager| BAE SystemsSouthport, Merseyside, United Kingdom
I have aldo been in this situation and I developed the WBS from the information gathered prior to the project initiation (conecpt phase).
I then used the WBS as the tick off diagram/structure. I review this in 1 session with the high level (managers) stakeholders to validate that processes/procedures/documents had not changed from their perspective.
I then went through an additional lower level brainstorming session with the individual business unit Managers/team leaders to grow the WBS further to then enable me to create workstreams/work packages.
So very similar to what Mark has said.
Saving Changes...
Andrew MakarProgram Manager| AMAKAR LLCOakland Township, Mi, United States
How does the company leverage the brainstorming?
Do they use any existing tools to capture the use cases or background information? As other have indicated, building a graphical WBS from all this information will help confirm scope and identify all the key deliverables that need to be created.
In the consulting world, the term RICEF is frequently used to refer to reports, interfaces, conversions, enhancements and form changes. Build a WBS that supports the generation of these deliverables is useful in not only defining the scope but graphically tracking progress.
Take a look at Figure 3 in this article on Gantthead:
Don't Fear the WBS
It sounds like that at the time of WBS creating there are plenty of documents/specifications/prototypes etc. This is great, because it really make the process easier.
If the specs are not ready, you can still get the WBS done, but label it "preliminary", which means that it's still subject to change as specification are signed off.
Assuming all specs/prototypes are signed off, i would personally not call a "brainstorming meeting" to get the WBS done. Also assuming that there is a team of software experts tasked to deliver the solution, i would ask the technical experts to draw up the WBS and forward onto me. If the work units are dependent on different teams, i would get the teams to use a single WBS. A simple WBS template can be created to enable to the team to complete what is required.
Once i have the WBS, i would create the plan, and then setup a meeting to go through the plan. I feel that this is more productive, it will eventually reduce the number of meetings required for WBS completion. And technical resources won’t feel bogged down by too many meetings.
Saving Changes...
